Re: Numa=on broken?

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

* Subrahmanian, Raj <raj.subrahmanian@unisys.com> [2007-05-07 15:25]:
> Ryan,
> >> > Ryan,
> >> > I did check out the mail discussion where you encountered 
> >and fixed 
> >> > this.
> >> > I am seeing this again on 15009, unstable and in 15021 3.1. rc7.
> >> > I have included the debug messages in both runs.
> >> 
> >> Hrm, well, we need to see which node the request is failing in so we 
> >> can figure out how to initialize the heap.  I'm attaching a 
> >patch that 
> >> should hopefully dump out which node the memory request is 
> >failing in.
> >> 
> >> Last time, it was the xmalloc() in xen/common/page_alloc.c in 
> >> init_heap_pages().
> >> 
> >> Give this patch a spin and email me the output.
> >
> >Here is one that actually compiles.
> Here's the output..
> Unstable tree. Changeset 15009.

Do you have the SRAT table information, we need to know if you have any 
memory in node0.  I believe this code relies on the xenheap residing in 
node0.
   
The call chain is likely:
   
xen/arch/x86/setup.c:calls init_xenheap_pages()
xen/common/page_alloc.c: init_heap_pages()

if the memory being added to the heap belongs to node1, the structure
is dynamically allocated using xmalloc() which will request a page
from the heap which is no memory is already in the heap, we fail.

That's what this looks like.  You can confirm this by adding some debug 
to the init_heap_pages() function in xen/common/page_alloc.c.

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