[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-ia64-devel] RE: Xen/ia64 - global or per VP VHPT
> When implementing the lVHPT in Linux I decided on a per-CPU > VHPT for the > scalability reasons that you cite. And one drawback is, as Dan says, > that it may be difficult to find a large enough chunk of free physical > memory to bring up a new processor (or domain in the per-domain case). Thanks for chiming in Matt! Wow, I hadn't even realized before you mentioned it... a lVHPT is generally contiguous in physical memory because it has to be pinned by a TR (or more than one TR, but there's not many to choose from!). That may not be a problem when you know in advance how many domains are going to run on the machine and you partition the memory in advance, but it's a HUGE disadvantage for per-domain VHPT in the highly dynamic environment we envision at HP, with domains being frequently created, growing, shrinking, and migrating. E.g. creating a domain may require a massive defrag operation to just allocate the per-domain VHPT. And growing/shrinking a per-domain VT dynamically is MUCH more difficult. I see that as a HUGE problem for using per-domain VHPTs for VT domains too. Or am I missing something? This is an excellent example of how assumptions can influence design... Now back (finally) to my regularly scheduled weekend :-) _______________________________________________ Xen-ia64-devel mailing list Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-ia64-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |