linux-kernel - Re: [00/17] Large Blocksize Support V3

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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/