On Fri, Apr 27, 2007 at 12:26:40AM -0700, Andrew Morton wrote:
> On Fri, 27 Apr 2007 00:19:49 -0700 (PDT) Christoph Lameter <[EMAIL
> PROTECTED]> wrote:
>
> > The page cache handling in the various layers is significantly
> > simplified which reduces maintenance cost.
>
> How on earth can the *addition* of variable pagecache size simplify the
> existing code?
>
> What cleanups are in this patchset which cannot be made *without* the
> addition of variable pagecache size?
I think this is the cleanup of all the open coded masking and offset
to index type of operations that get done over and over again everywhere.
> > Dave, where are we with the performance tests?
>
> Well yes.
Backed up behind real work ;)
The test was writing a single 50GB file to a fresh filesystem, and
then reading it back. Run on two different dm stripes - a 4-disk
RAID) and a 8disk RAID0 stripe, with a stripe unit of 512k. Disks
are 10krpm SAS, external jbod on PCI-X good for ~850MB/s read and
~750MB/s write. Server is 4p intel x86_64 with 16GB RAM.
READ WRITE
blksz disks tput sys tput sys
----- ----- ----- ---- ----- ----
4k 4 332 35s 203 76s
64k 4 173 20s 273 21s
4k 8 403 35s 443 76s
64k 8 634 21s 540 21s
Throughput in MB/s.
So, there's some interaction between reads and large block size;
may be related to readahead but i haven't looked into I/O
patterns at this stage.
More results soonish.....
Cheers,
Dave.
--
Dave Chinner
Principal Engineer
SGI Australian Software Group
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
