On Fri, Apr 27, 2007 at 12:26:40AM -0700, Andrew Morton wrote:
quoted text
> On Fri, 27 Apr 2007 00:19:49 -0700 (PDT) Christoph Lameter <clameter@sgi.com> 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.

quoted text
> > 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
-
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/