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:55:33 -0500
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 30 Mar 2007 19:56:07 +0100
Envelope-to: Keir.Fraser@xxxxxxxxxxxx
In-reply-to: <C2331ABF.52F4%Keir.Fraser@xxxxxxxxxxxx>
References: <20070330184620.GV28736@xxxxxxxxxx> <C2331ABF.52F4%Keir.Fraser@xxxxxxxxxxxx>
User-agent: Mutt/1.5.6+20040907i
* Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> [2007-03-30 13:52]:
> 
> 
> 
> On 30/3/07 19:46, "Ryan Harper" <ryanh@xxxxxxxxxx> wrote:
> 
> > That is, we are still dying in init_heap_pages(), but this time for
> > allocating avail[0] rather than avail[1].
> 
> In addition to that change in x86/setup.c, move the first three lines of
> code from end_boot_allocator() into init_xenheap_pages() (these are the ones
> that actually set up the statically allocated node0 metadata). If that works
> I'll sort out a clean fix.
> 
> This is just a simple exercise in code shuffling. :-)

Giving that try right now, let you know in a fewl.

I would have rather had the folks who changed the code actually test
with numa=on.

What are you thoughts about turning numa on by default or at least
getting a numa=on run on a two-socket opteron in the xen-rt regressions.

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