From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ryan Harper Subject: Re: numa=on broken Date: Fri, 30 Mar 2007 13:08:53 -0500 Message-ID: <20070330180853.GT28736@us.ibm.com> References: <20070330173432.GR28736@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: 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: Ryan Harper , xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org * Keir Fraser [2007-03-30 13:06]: > On 30/3/07 18:34, "Ryan Harper" 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