This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: "Aron Griffis" <aron@xxxxxx>, "Ian Pratt" <Ian.Pratt@xxxxxxxxxxxx>
Subject: RE: [Xen-devel] [RFC] Xen NUMA strategy
From: "Ian Pratt" <Ian.Pratt@xxxxxxxxxxxx>
Date: Wed, 19 Sep 2007 02:04:53 +0100
Cc: Andre Przywara <andre.przywara@xxxxxxx>, "Xu, Anthony" <anthony.xu@xxxxxxxxx>, Akio Takebe <takebe_akio@xxxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 18 Sep 2007 18:06:28 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <51CFAB8CB6883745AE7B93B3E084EBE2011113AE@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <8A87A9A84C201449A0C56B728ACF491E260723@xxxxxxxxxxxxxxxxxxxxxxxxxxx> <20070918133036.GB8468@xxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acf5+ArMyL0SLDWRQBy1AqssFjO2OAALjT1A
Thread-topic: [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.


Xen-devel mailing list