From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ryan Harper Subject: Re: numa=on broken Date: Fri, 30 Mar 2007 13:46:20 -0500 Message-ID: <20070330184620.GV28736@us.ibm.com> References: <20070330180853.GT28736@us.ibm.com> <20070330182058.GU28736@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <20070330182058.GU28736@us.ibm.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org * Ryan Harper [2007-03-30 13:36]: > * Keir Fraser [2007-03-30 13:17]: > > > > > > > > On 30/3/07 19:08, "Ryan Harper" 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. Didn't work, just pushes the bubble back to allocating the array for NODE0: (XEN) SRAT: Node 0 PXM 0 0-a0000 (XEN) SRAT: Node 0 PXM 0 0-e0000000 (XEN) SRAT: Node 1 PXM 1 100000000-200000000 (XEN) NUMA: Using 32 for the hash shift. (XEN) done with numa_initmem_init() (XEN) attempting to xmalloc_array() avail for NODE0 (XEN) Cannot handle page request order 0! (XEN) attempting to xmalloc() for heap for NODE0 (XEN) Cannot handle page request order 2! That is, we are still dying in init_heap_pages(), but this time for allocating avail[0] rather than avail[1]. -- Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx (512) 838-9253 T/L: 678-9253 ryanh@us.ibm.com