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] numa=on broken

To: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] numa=on broken
From: Ryan Harper <ryanh@xxxxxxxxxx>
Date: Fri, 30 Mar 2007 13:20:58 -0500
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 30 Mar 2007 19:21:22 +0100
Envelope-to: Keir.Fraser@xxxxxxxxxxxx
In-reply-to: <C23312CA.52E9%Keir.Fraser@xxxxxxxxxxxx>
References: <20070330180853.GT28736@xxxxxxxxxx> <C23312CA.52E9%Keir.Fraser@xxxxxxxxxxxx>
User-agent: Mutt/1.5.6+20040907i
* Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> [2007-03-30 13:17]:
> 
> 
> 
> On 30/3/07 19:08, "Ryan Harper" <ryanh@xxxxxxxxxx> wrote:
> 
> >> 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
> 
> What if you move end_boot_allocator() to just before 'early_boot = 0' in
> arch/x86/setup.c?

Giving that a shot.  

Debugging shows confirms that we are looking at node0 memory which
should have already been initialized in the allocator:

(XEN) NUMA: Using 32 for the hash shift.
(XEN) attempting to xmalloc_array() avail for NODE1
(XEN) alloc_xenheap_pages: Requesting MEMZONE_XEN, cpu0, order->0
(XEN) alloc_heap_pages: attempting to allocate in zone(0,0), cpu0, node0, 
order->0
(XEN) Cannot handle page request order 0!

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