[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.