From: Nick Piggin Subject: Re: [00/41] Large Blocksize Support V7 (adds memmap support) Date: Fri, 14 Sep 2007 06:51:29 +1000 Message-ID: <200709140651.30735.nickpiggin@yahoo.com.au> References: <20070911060349.993975297@sgi.com> <200709120407.48344.nickpiggin@yahoo.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: Mel Gorman , andrea@suse.de, torvalds@linux-foundation.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Christoph Hellwig , Mel Gorman , William Lee Irwin III , David Chinner , Jens Axboe , Badari Pulavarty , Maxim Levitsky , Fengguang Wu , swin wang , totty.lu@gmail.com, hugh@veritas.com, joern@lazybastard.org To: Christoph Lameter Return-path: Received: from smtp108.mail.mud.yahoo.com ([209.191.85.218]:23645 "HELO smtp108.mail.mud.yahoo.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1753777AbXINMoZ (ORCPT ); Fri, 14 Sep 2007 08:44:25 -0400 In-Reply-To: Content-Disposition: inline Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Thursday 13 September 2007 09:06, Christoph Lameter wrote: > On Wed, 12 Sep 2007, Nick Piggin wrote: > > So lumpy reclaim does not change my formula nor significantly help > > against a fragmentation attack. AFAIKS. > > Lumpy reclaim improves the situation significantly because the > overwhelming majority of allocation during the lifetime of a systems are > movable and thus it is able to opportunistically restore the availability > of higher order pages by reclaiming neighboring pages. I'm talking about non movable allocations. > > [*] ok, this isn't quite true because if you can actually put a hard > > limit on unmovable allocations then anti-frag will fundamentally help -- > > get back to me on that when you get patches to move most of the obvious > > ones. > > We have this hard limit using ZONE_MOVABLE in 2.6.23. So we're back to 2nd class support. > > Sure, and I pointed out the theoretical figure for 64K pages as well. Is > > that figure not problematic to you? Where do you draw the limit for what > > is acceptable? Why? What happens with tiny memory machines where a > > reserve or even the anti-frag patches may not be acceptable and/or work > > very well? When do you require reserve pools? Why are reserve pools > > acceptable for first-class support of filesystems when it has been very > > loudly been made a known policy decision by Linus in the past (and for > > some valid reasons) that we should not put limits on the sizes of caches > > in the kernel. > > 64K pages may problematic because it is above the PAGE_ORDER_COSTLY in > 2.6.23. 32K is currently much safer because lumpy reclaim can restore > these and does so on my systems. I expect the situation for 64K pages to > improve when more of Mel's patches go in. We have long term experience > with 32k sized allocation through Andrew's tree. > > Reserve pools as handled (by the not yet available) large page pool > patches (which again has altogether another purpose) are not a limit. The > reserve pools are used to provide a mininum of higher order pages that is > not broken down in order to insure that a mininum number of the desired > order of pages is even available in your worst case scenario. Mainly I > think that is needed during the period when memory defragmentation is > still under development. fsblock doesn't need any of those hacks, of course.