[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070428104328.0b609fb6@the-village.bc.nu>
Date: Sat, 28 Apr 2007 10:43:28 +0100
From: Alan Cox <alan@...rguk.ukuu.org.uk>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: David Chinner <dgc@....com>, Christoph Lameter <clameter@....com>,
linux-kernel@...r.kernel.org, Mel Gorman <mel@...net.ie>,
William Lee Irwin III <wli@...omorphy.com>,
Jens Axboe <jens.axboe@...cle.com>,
Badari Pulavarty <pbadari@...il.com>,
Maxim Levitsky <maximlevitsky@...il.com>,
Nick Piggin <nickpiggin@...oo.com.au>
Subject: Re: [00/17] Large Blocksize Support V3
On Fri, 27 Apr 2007 21:56:34 -0700
Andrew Morton <akpm@...ux-foundation.org> wrote:
> On Sat, 28 Apr 2007 13:17:40 +1000 David Chinner <dgc@....com> wrote:
>
> > > Fix up your lameo HBA for reads.
> >
> > Where did that come from? You spend 20 lines described the inefficiencies
> > of the readahead in the page cache and it should be fixed but then you
> > turn around and say fix the HBA?
>
> My (repeated) point is that if we populate pagecache with physically-contiguous 4k
> pages in this manner then bio+block will be able to create much larger SG lists.
Also remember that even if you do larger pages by using virtual pairs or
quads of real pages because it helps on some systems you end up needing
the same sized sglist as before so you don't make anything worse for
half-assed controllers as you get the same I/O size providing they have
the minimal 2 or 4 sg list entries (and those that don't are genuinely
beyond saving and nowdays very rare)
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists