From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Fri, 4 Nov 2005 01:26:51 +0000 (GMT) From: Mel Gorman Subject: Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19 In-Reply-To: Message-ID: References: <4366C559.5090504@yahoo.com.au> <1130854224.14475.60.camel@localhost><20051101142959.GA9272@elte.hu> <1130856555.14475.77.camel@localhost><20051101150142.GA10636@elte.hu> <1130858580.14475.98.camel@localhost><20051102084946.GA3930@elte.hu> <436880B8.1050207@yahoo.com.au><1130923969.15627.11.camel@localhost> <43688B74.20002@yahoo.com.au><255360000.1130943722@[10.10.2.4]> <4369824E.2020407@yahoo.com.au> <306020000.1131032193@[10.10.2.4]> <1131032422.2839.8.camel@laptopd505.fenrus.org> <309420000.1131036740@[10.10.2.4]> <311050000.1131040276@[10.10.2.4]> <1131040786.2839.18.camel@laptopd505.fenrus.org> <312300000.1131041824@[10.1! 0.2.4]> <436AB241.2030403@yahoo.com.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org Return-Path: To: Linus Torvalds Cc: Nick Piggin , "Martin J. Bligh" , Arjan van de Ven , Dave Hansen , Ingo Molnar , Andrew Morton , kravetz@us.ibm.com, linux-mm , Linux Kernel Mailing List , lhms , Arjan van de Ven List-ID: On Thu, 3 Nov 2005, Linus Torvalds wrote: > > > On Fri, 4 Nov 2005, Nick Piggin wrote: > > > > Looks like ppc64 is getting 64K page support, at which point higher > > order allocations (eg. for stacks) basically disappear don't they? > > Yes and no, HOWEVER, nobody sane will ever use 64kB pages on a > general-purpose machine. > > 64kB pages are _only_ usable for databases, nothing else. > Very well, but if the infrastructure required to help get 64kB pages still performs the same, or better, than the current infrastructure that gives 4kB pages, then why not? I am biased obviously and probably optimistic but I am hoping we have a case here where we get our cake and eat it twice. > Why? Do the math. Try to cache the whole kernel source tree in 4kB pages > vs 64kB pages. See how the memory usage goes up by a factor of _four_. > I don't know, but I doubt they would use 64kB pages as the default size unless it is a specialised machine. I could be wrong, I don't have a ppc64 machine, I don't work on a ppc64 machine, I haven't read the architectures documentation and I didn't write this code for a ppc64 machine. If the machine here in question it's a specialised machine, they go into the 0.01% category of people, but it's a group that we can still help without introducing static zones they have to configure. I'm still waiting on figures that say the approach proposed here is actually really slow, rather than makes people unhappy slow. If this is proved to be slow, then I'll admit there is a problem and put more effort into the plans to use zones instead. I just haven't found a problem on the machines I have available to me, be it aim9, bench-stresshighalloc or building kernels (which I think is important considering how often I build test kernels). If it's a documentation problem with these patches, I'll write up VM docs on the allocator and submit it as a patch, complete with downsides and caveats to be fair. -- Mel Gorman Part-time Phd Student Java Applications Developer University of Limerick IBM Dublin Software Lab -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org