Re: numa=on broken

[Ryan Harper <ryanh@us.ibm.com>]

* Keir Fraser <Keir.Fraser@cl.cam.ac.uk> [2007-03-30 13:06]:
> On 30/3/07 18:34, "Ryan Harper" <ryanh@us.ibm.com> wrote:
> 
> > Looking a little deeper, it looks like in end_boot_allocator() we are
> > attempting to dynamically allocate memory for addition arrays in avail[]
> > and for the heap.  This uses xmalloc() which relies on
> > alloc_xenheap_pages() to work.  alloc_xenheap_pages() can't function
> > until end_boot_allocator() completes.  Prior to end_boot_alloctor(), one
> > needs to use alloc_boot_pages().
> > 
> > Any thoughts on how to proceed here?
> 
> Since the buddy allocators are initialised with memory from address zero
> upwards, I would expect everything to work fine if numa node zero always
> owns the first block of physical memory. This is because we statically
> allocate space for heap metadata for numa node zero (since even non-numa
> machines have a 'numa node zero'), so by the time you need to allocate
> memory for other numa nodes you're xenheap will be populated with memory.
> 
> So -- can we ensure that the node that owns low memory is node zero?

AFAIK, that is the case, look at the SRAT table:

(XEN) SRAT: Node 0 PXM 0 0-a0000
(XEN) SRAT: Node 0 PXM 0 0-e0000000
(XEN) SRAT: Node 1 PXM 1 100000000-200000000

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