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

Re: [Xen-devel] [PATCH]: Allow Xen to boot/run on large memory (>64G) machines

  • To: Chris Lalancette <clalance@xxxxxxxxxx>
  • From: Keir Fraser <keir@xxxxxxxxxxxxx>
  • Date: Thu, 22 Feb 2007 15:11:50 +0000
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Jan Beulich <jbeulich@xxxxxxxxxx>
  • Delivery-date: Thu, 22 Feb 2007 07:11:57 -0800
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcdWk8beBXw94sKHEdubSQAX8io7RQ==
  • Thread-topic: [Xen-devel] [PATCH]: Allow Xen to boot/run on large memory (>64G) machines

On 22/2/07 14:57, "Chris Lalancette" <clalance@xxxxxxxxxx> wrote:

>> It makes sense for the boot allocator to prefer to allocate from high memory
>> if it can, rather then using what is currently the DMA pool (and, after your
>> patches are applied, will be from relatively-narrow-address-width pools). So
>> I think this patch is good and narrow enough in scope to go straight in
>> (although I think the behaviour of alloc_boot_pages() should be changed
>> rather than adding a new allocator function).
> Yeah, I wasn't quite sure how far to go with this.  The frame table was the
> worst offender, so I just went after that.  I can whip up a quick patch and
> test
> it out here, changing the alloc_boot_pages() to always allocate from the top.

Turns out there is one place that wants to allocate from the bottom (the
kdump path in arch/x86/setup.c). So I renamed alloc_boot_pages() to
alloc_lowmem_boot_pages() and called the new function alloc_boot_pages(). If
you care you use the more specific (lowmem) one. I'm about to check in the
revised patch.

> By the way, I assume we only want to do this for x86_64, yes?

No, it makes sense to conserve 'narrower' addresses.

 -- Keir

Xen-devel mailing list



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