[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] numa=on broken


  • To: Ryan Harper <ryanh@xxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
  • Date: Fri, 30 Mar 2007 18:51:22 +0100
  • Delivery-date: Fri, 30 Mar 2007 19:04:04 +0100
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: Acdy9AcYRV2Nht7nEdusYQAWy6hiGQ==
  • Thread-topic: [Xen-devel] numa=on broken

On 30/3/07 18:34, "Ryan Harper" <ryanh@xxxxxxxxxx> 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?

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.