[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070428122908.58f81808@the-village.bc.nu>
Date: Sat, 28 Apr 2007 12:29:08 +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
> But all (both) the proposals we're (ahem) discussing do involve 4x
> physically contiguous pages going into those four contiguous pagecache
> slots.
>
> So we're improving things for the half-assed controllers, aren't we?
Not neccessarily. If you use 16K contiguous pages you have to do
more work to get memory contiguously and you have less cache efficiency
both of which will do serious damage to performance with poor I/O
subsystems for all the extra paging and I/O, and probably way more than
sglist stuff on PC class boxes. (yes its probably a win on your 32GB SGI
monster)
That aside you are improving things for most but not all half-assed
controllers (some sglists are simply page pointers for each 4K page or
have different efficient encoding for page sized chunks (I2O). If you are
reading large chunks on a really crap controller (eg IDE in PIO) then the
fact you pull 16K when you need 4K will also wipe out any gains.
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