linux-kernel - Re: More Large blocksize benchmarks

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 for Android: free password hash cracker in your pocket

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

Message-Id: <1192539661.25603.38.camel@think.oraclecorp.com>
Date:	Tue, 16 Oct 2007 09:01:01 -0400
From:	Chris Mason <chris.mason@...cle.com>
To:	David Chinner <dgc@....com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Nathan Scott <nscott@...nex.com>,
	Andrea Arcangeli <andrea@...e.de>,
	Nick Piggin <nickpiggin@...oo.com.au>,
	Christoph Lameter <clameter@....com>,
	Mel Gorman <mel@...net.ie>, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org, Christoph Hellwig <hch@....de>,
	William Lee Irwin III <wli@...omorphy.com>,
	Jens Axboe <jens.axboe@...cle.com>,
	Badari Pulavarty <pbadari@...il.com>,
	Maxim Levitsky <maximlevitsky@...il.com>,
	Fengguang Wu <fengguang.wu@...il.com>,
	swin wang <wangswin@...il.com>, totty.lu@...il.com,
	hugh@...itas.com, joern@...ybastard.org
Subject: Re: More Large blocksize benchmarks

On Tue, 2007-10-16 at 12:36 +1000, David Chinner wrote:
> On Mon, Oct 15, 2007 at 08:22:31PM -0400, Chris Mason wrote:
> > Hello everyone,
> > 
> > I'm stealing the cc list and reviving and old thread because I've
> > finally got some numbers to go along with the Btrfs variable blocksize
> > feature.  The basic idea is to create a read/write interface to
> > map a range of bytes on the address space, and use it in Btrfs for all
> > metadata operations (file operations have always been extent based).
> > 
> > So, instead of casting buffer_head->b_data to some structure, I read and
> > write at offsets in a struct extent_buffer.  The extent buffer is very
> > small and backed by an address space, and I get large block sizes the
> > same way file_write gets to write to 16k at a time, by finding the
> > appropriate page in the addess space.  This is an over simplification
> > since I try to cache these mapping decisions to avoid using too much
> > CPU, but hopefully you get the idea.
> > 
> > The advantage to this approach is the changes are all inside Btrfs.  No
> > extra kernel patches were required.
> > 
> > Dave reported that XFS saw much higher write throughput with large
> > blocksizes, but so far I'm seeing the most benefits during reads.
> 
> Apples to oranges, Chris ;)
> 

Grin, if the two were the same, there'd be no reason to write a new one.
I didn't expect faster writes on btrfs, at least not for workloads that
did not require reads.  The basic idea is to show there are a variety of
ways the larger blocks can improve (and hurt) performance.

Also, vmap isn't the only implementation path.  Its true the Btrfs
changes for this were huge, but a big chunk of the changes were for
different leaf/node blocksizes, something that may never get used in
practice.

-chris


-
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/