RE: [Xen-devel] [RFC] Xen NUMA strategy

["Ian Pratt" <Ian.Pratt@xxxxxxxxxxxx>]

> 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