Date: Fri, 14 Sep 2007 10:52:53 -0700 (PDT)
From: Christoph Lameter <clameter@sgi.com>
To: Nick Piggin <nickpiggin@yahoo.com.au>
cc: Mel Gorman <mel@csn.ul.ie>, andrea@suse.de, torvalds@linux-foundation.org,
       linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
       Christoph Hellwig <hch@lst.de>, Mel Gorman <mel@skynet.ie>,
       William Lee Irwin III <wli@holomorphy.com>, David Chinner <dgc@sgi.com>,
       Jens Axboe <jens.axboe@oracle.com>,
       Badari Pulavarty <pbadari@gmail.com>,
       Maxim Levitsky <maximlevitsky@gmail.com>,
       Fengguang Wu <fengguang.wu@gmail.com>, swin wang <wangswin@gmail.com>,
       totty.lu@gmail.com, hugh@veritas.com, joern@lazybastard.org
Subject: Re: [00/41] Large Blocksize Support V7 (adds memmap support)
In-Reply-To: <200709140651.30735.nickpiggin@yahoo.com.au>
Message-ID: <Pine.LNX.4.64.0709141048320.15813@schroedinger.engr.sgi.com>
References: <20070911060349.993975297@sgi.com> <200709120407.48344.nickpiggin@yahoo.com.au>
 <Pine.LNX.4.64.0709121551340.4204@schroedinger.engr.sgi.com>
 <200709140651.30735.nickpiggin@yahoo.com.au>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1662
Lines: 37

On Fri, 14 Sep 2007, Nick Piggin wrote:

> > > [*] 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.

2nd class support for me means a feature that is not enabled by default 
but that can be enabled in order to increase performance. The 2nd class 
support is there because we are not yet sure about the maturity of the 
memory allocation methods.

 
> > 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.

Nor does mine for the low orders that we are considering. For order > 
MAX_ORDER this is unavoidable since the page allocator cannot manage such 
large pages. It can be used for lower order if there are issues (that I 
have not seen yet).

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/