[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-devel] [RFC] Xen NUMA strategy
> Ian Pratt wrote: [Tue Sep 18 2007, 04:43:24AM EDT] > > However, there's a bunch of scalability works that's required in Xen > > before this will really make sense, and all of this is much higher > > priority (and more generally useful) than figuring out how to expose > > NUMA topology to guests. > > Could you elaborate on this sentence? What are you thinking of? Eliminating the need to hold the domain lock for pagetable updates for PV guests would certainly be a guest scalability win. The page ref counting is designed to make this possible. Similarly, HVM guests would benefit from optimizing the amount of time the shadow lock is held for (eliminating it altogether is harder). [NB: per VCPU shadows is one strategy for removing the lock but it brings with it a whole host of other synchronization issues that make me strongly suspect its not worth it.] Xen's CPU scheduler could certainly do with some improvements when it comes to multiple multi-CPU guests. We probably want behaviour that tends towards gang scheduling yet remains work conserving. We also need some kind of "bad pre-emption" avoidance or mitigation strategy to avoid other VCPUs spinning waiting for a VCPU that isn't running. We could implement avoidance by giving a VCPU some extra time if its holding a lock at the point we pre-empt it, the latter by doing a directed yield in the lock slow path if the VCPU holding the lock is not running. Both require a new paravirtualization extension to the OS. Ian _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |