WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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: Thu, 20 Sep 2007 10:50:26 +0100
Cc: Andre Przywara <andre.przywara@xxxxxxx>, "Xu, Anthony" <anthony.xu@xxxxxxxxx>, Akio Takebe <takebe_akio@xxxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 20 Sep 2007 02:52:30 -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> <20070920030937.GI28555@xxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acf7M8bLS+Q9Uw2RRMiJx0z7qBU4yQAN4vjQ
Thread-topic: [Xen-devel] [RFC] Xen NUMA strategy
> Ian Pratt wrote:  [Tue Sep 18 2007, 04:43:24AM EDT]
> > The way I see it, in most situations it will not make sense for
guests
> > to span NUMA nodes: you'll have a number of guests with relatively
small
> > numbers of vCPUs, and it probably makes sense to allow the guests to
be
> > pinned to nodes. What we have in Xen today works pretty well for
this
> > case, [snip]
> 
> One part that doesn't work well presently is memory locality.  A guest
> can be pinned to a CPU but its allocated memory might be on a distant
> node...

If the guest's VCPUs were pinned to a particular node (or nodes) at the
time the domain was created or additional memory was allocated to it,
then the memory *will* be allocated from the right node(s). If you have
a domain CPU mask that covers multiple nodes, memory will be 'striped'
across the nodes.

Ian

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel