From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Lameter Subject: Re: [00/41] Large Blocksize Support V7 (adds memmap support) Date: Mon, 17 Sep 2007 15:05:18 -0700 (PDT) Message-ID: References: <20070911060349.993975297@sgi.com> <200709140651.30735.nickpiggin@yahoo.com.au> <200709161822.47879.nickpiggin@yahoo.com.au> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: Nick Piggin Return-path: In-Reply-To: <200709161822.47879.nickpiggin@yahoo.com.au> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Sun, 16 Sep 2007, Nick Piggin wrote: > > > 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). > > Or we can just avoid all doubt (and doesn't have arbitrary limitations > according to what you think might be reasonable or how well the > system actually behaves). We can avoid all doubt in this patchset as well by adding support for fallback to a vmalloced compound page.