From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Lalancette Subject: Re: [PATCH]: Allow Xen to boot/run on large memory (>64G) machines Date: Thu, 22 Feb 2007 09:57:10 -0500 Message-ID: <45DDAF46.60404@redhat.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: 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: xen-devel@lists.xensource.com, Jan Beulich List-Id: xen-devel@lists.xenproject.org Keir Fraser wrote: > On 22/2/07 10:33, "Jan Beulich" wrote: > > >>The page allocator changes that I posted a while back probably haven't >>been looked at so fat, given the above comments. The patch that kills the >>DMA pool changes x86-64 to allocate the dom0 memory without restriction >>(i386 has to remain restricted, yet not because of DMA address issues, but >>in order to be able to see the memory in the 1:1 mapping). > > > Oh, good point. :-) And it sounds like it makes sense to leave this alone > for now and leave it to your patches. > Ah, OK. That will address the second concern. Jan's right, I didn't actually look at those patches. Thanks for pointing them out. > > 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. By the way, I assume we only want to do this for x86_64, yes? Chris Lalancette