From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754927AbXDZS2b (ORCPT ); Thu, 26 Apr 2007 14:28:31 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754929AbXDZS2b (ORCPT ); Thu, 26 Apr 2007 14:28:31 -0400 Received: from brick.kernel.dk ([80.160.20.94]:17016 "EHLO kernel.dk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754926AbXDZS2a (ORCPT ); Thu, 26 Apr 2007 14:28:30 -0400 Date: Thu, 26 Apr 2007 20:24:48 +0200 From: Jens Axboe To: Christoph Hellwig , Christoph Lameter , "Eric W. Biederman" , Nick Piggin , David Chinner , linux-kernel@vger.kernel.org, Mel Gorman , William Lee Irwin III , Badari Pulavarty , Maxim Levitsky Subject: Re: [00/17] Large Blocksize Support V3 Message-ID: <20070426182447.GI2017@kernel.dk> References: <46303A98.9000605@yahoo.com.au> <20070426063830.GE32602149@melbourne.sgi.com> <46304B9E.5070604@yahoo.com.au> <20070426161152.GC16337@infradead.org> <20070426180358.GG2017@kernel.dk> <20070426180932.GA10642@infradead.org> <20070426181249.GH2017@kernel.dk> <20070426182456.GA13066@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070426182456.GA13066@infradead.org> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 26 2007, Christoph Hellwig wrote: > On Thu, Apr 26, 2007 at 08:12:51PM +0200, Jens Axboe wrote: > > > Exactly. But the only counter-proposal we have so far seems far worse :) > > > > Lets look at some numbers. I'll just concentrate on the scatterlist, > > since the bio_vec is smaller. On x86 32-bit, the scatterlist is 20 bytes > > long. If we accept that 2^1 allocations are ok (they should be), then we > > can support ~1.6mb ios just like that. > > > > My approach would be to support scatterlist chaining. Essentially you'd > > have the last element of the sglist pointing to the next array of > > entries. We can then stick to 128 entry arrays which fit nicely in a > > single page allocation and easily support >> 2mb ios. The only caveat is > > that you'd need to update the drivers to get there, since a regular > > iteration over the array isn't enough. My plan was to add an sglist > > iterator helper that hides this from the drivers, if they need to loop > > over the scatterlist. Things like {dma/pci}_map_sg() would of course be > > updated. > > > > The above can be implemented fairly cleanly, and on a need-to-have > > basis. It's not something that'll break drivers. > > > > What do you think? > > Purely for the I/O sizes to external arrays problem that's nice, > and I think we (well, you :)) should implement it. I will get it implemented, next week. > But there's other reasons why larger objects in the page cache make > sense that are mostly related to keeping overhead for large files > in the operating system down. So I'd go both for s/g list chaining > and variable order pagecache. Oh I definitely agree, I just think we should keep the discussion focused on the seperate issues and not mix everything up. > Btw, we should talk a little about the sglist iterators on linux-scsi, > as a lot of the dma mapping API will need updates for bidirection dmas > anyway, and we should try to get everything done in one rush. Yep -- Jens Axboe