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] XEN memory management(NUMA or otherwise) TODOs

To: Dulloor <dulloor@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] XEN memory management(NUMA or otherwise) TODOs
From: Ian Pratt <Ian.Pratt@xxxxxxxxxxxxx>
Date: Fri, 31 Jul 2009 22:42:30 +0100
Accept-language: en-US
Acceptlanguage: en-US
Cc: Ian Pratt <Ian.Pratt@xxxxxxxxxxxxx>
Delivery-date: Fri, 31 Jul 2009 14:43:00 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <940bcfd20907302208h2d9d2c0di11db1a6a6758bf6@xxxxxxxxxxxxxx>
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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <940bcfd20907302208h2d9d2c0di11db1a6a6758bf6@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcoRnRuIB+TE3zOVTzuyvJjOK+IvswAg/y3Q
Thread-topic: [Xen-devel] XEN memory management(NUMA or otherwise) TODOs
> Subject: [Xen-devel] XEN memory management(NUMA or otherwise) TODOs
> Any ideas anyone ?

There are a few things that spring to mind:

 * incremental page migration. If the affinity mask associated with domain 
changes, it might be nice to incrementally migrate pages as appropriate for the 
new mask (i.e. striped across the nodes included in the affinity set).

 * we definitely need to review the striping policy in light of the performance 
gains to be had using 2MB pages with HAP -- we may already be doing the right 
thing, but I'm not sure.

 * option to expose real NUMA information into the guest, hence allocate 
contiguous memory chunks from the nodes in the affinity set, and then expose 
this information to guests. Individual VCPUs should be given affinity sets 
confining them to individual nodes.


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>