[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070427163620.GI32602149@melbourne.sgi.com>
Date: Sat, 28 Apr 2007 02:36:20 +1000
From: David Chinner <dgc@....com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Christoph Lameter <clameter@....com>, David Chinner <dgc@....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>
Subject: Re: [00/17] Large Blocksize Support V3
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 <clameter@....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.
> > 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 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