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 09:39:48 -0600
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Pierre Ossman <drzeus-list@...eus.cx>
Cc:	Christoph Lameter <clameter@....com>, linux-kernel@...r.kernel.org,
	Mel Gorman <mel@...net.ie>,
	William Lee Irwin III <wli@...omorphy.com>,
	David Chinner <dgc@....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

Pierre Ossman <drzeus-list@...eus.cx> writes:

> Eric W. Biederman wrote:
>> 
>> I have a hard time believe that device hardware limits don't allow them
>> to have enough space to handle larger requests.  If so it was a poor
>> design by the hardware manufacturers.
>> 
>
> In the MMC layer, the block size is a major bottle neck. None of the currently
> supported hardware supports scatter/gather so we're restricted to servicing a
> single continuous chunk of memory at a time. And since latency is substantial
> for MMC/SD, good performance is several orders above 4k. We get ~8 MB/s for
> cards which are supposed to do 20 MB/s (which has been tested against other
> systems where we can get larger memory chunks), and the peasants are getting a
> bit unruly.
>
> I plan to experiment with some bounce buffer scheme to get performance up, but
> getting large blocks directly would make such hacks unnecessary.

My problem with the proposed scheme is not that it uses large pages,
but rather that it requires large pages.  So in the mmc case you would
go from getting 20MB/s soon after the system booted to failing to be
able to do I/O at all a couple of days later when memory gets
fragmented.

I think a reliable 8MB/s is much better than an unreliable 20MB/s.

With your bounce buffer scheme it seems probable that we can even
get a reliable 20MB/s.

So I'm interested to hear that we have several in tree users that
could benefit.

I do think large block support if we don't require large pages makes
sense.

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