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


[Xen-devel] [PATCH 0/6] xen: Add NUMA support to Xen

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] [PATCH 0/6] xen: Add NUMA support to Xen
From: Ryan Harper <ryanh@xxxxxxxxxx>
Date: Mon, 1 May 2006 16:56:38 -0500
Cc: Ryan Grimm <grimm@xxxxxxxxxx>
Delivery-date: Mon, 01 May 2006 14:57:08 -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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.6+20040907i
The patchset will add basic NUMA support to Xen (hypervisor only).  We
borrowed from Linux support for NUMA SRAT table parsing, discontiguous
memory tracking (memchunk_t), and cpu support (node_to_cpumask etc).

The hypervisor parses the SRAT tables and constructs mappings for each
node such as node to cpu mappings and memory range to node mappings.

Using this information, we also modified the page allocator to provide a
simple NUMA-aware API.  The allocator is initialized on a per-node basis.
Upon bootup, memory is inserted into the proper per-node allocator based
on SRAT table information.   When requesting pages, the allocator will 
attempt to supply pages from a local node, but will use other non-local 
node memory to satisfy a particular zone or order request.

We also modified Xen's increase_reservation memory op to balance memory
distribution across the vcpus in use by a domain.  Relying on previous
patches which have already been committed to xen-unstable, a guest can be
constructed such that its entire memory is contained within a specific
NUMA node.

We export NUMA system information via the physinfo hypercall.  This
information provides cpu/memory topology and configuration information
gleaned from the SRAT tables to userspace applications.  Currently, xend
doesn't leverage any of the information automatically but we intend to
do so in the future.

There is a fix for some incorrect assumptions about the symmetry of NUMA
systems w.r.t the sockets_per_node value.  Details are available in a
later email with the patch.

We've added a new tool, xen_numastat, which dumps information about the
current heap free page status, as well as probing where a domain's
memory is from.  

These patches have been tested on several IBM NUMA and non-NUMA systems:

NUMA-aware systems: 
IBM Dual Opteron:  2 Node,  2 CPU,  4GB 
IBM x445        :  4 Node, 32 CPU, 32GB 
IBM x460        :  1 Node,  8 CPU, 16GB
IBM x460        :  2 Node, 32 CPU, 32GB
IBM x460        :  4 Node, 32 CPU, 24GB

Non NUMA-aware systems: 
IBM Dual Xeon   :  1 Node,  2 CPU,  2GB 
IBM P4          :  1 Node,  1 CPU,  1GB

We look forward to your review of the patches for acceptance.

Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-9253   T/L: 678-9253

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>
  • [Xen-devel] [PATCH 0/6] xen: Add NUMA support to Xen, Ryan Harper <=