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]
Message-ID: <20070426180212.GF2017@kernel.dk>
Date:	Thu, 26 Apr 2007 20:02:12 +0200
From:	Jens Axboe <jens.axboe@...cle.com>
To:	Christoph Lameter <clameter@....com>
Cc:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Mel Gorman <mel@...net.ie>,
	Nick Piggin <nickpiggin@...oo.com.au>,
	David Chinner <dgc@....com>, linux-kernel@...r.kernel.org,
	William Lee Irwin III <wli@...omorphy.com>,
	Badari Pulavarty <pbadari@...il.com>,
	Maxim Levitsky <maximlevitsky@...il.com>
Subject: Re: [00/17] Large Blocksize Support V3

On Thu, Apr 26 2007, Christoph Lameter wrote:
> On Thu, 26 Apr 2007, Eric W. Biederman wrote:
> 
> > I can't possibly believe any of this is about the cost of processing
> > a request, but rather the problem that some devices don't have a large
> > enough pool of requests to keep them busy if you submit the requests
> > in a 4K page sizes.
> > 
> > This all sounds like a device design issue rather than anything more
> > significant, and it doesn't sound like a long term trend.  Market
> > pressure should fix the hardware.
> 
> Sounds like we are dictating device manufacturers how to 
> design their devices instead of leaving them choice.

Well... First of all (to Eric), the 4kb pages isn't the issue. Only if
you have limited sg capabilities in your hardware AND need larger
segment sizes to get up in the range of request sizes that makes that
hardware go fast would you benefit from always using bigger pages. And
market pressure should indeed make you lose, if you design crappy
hardware like that.

Secondly, choice isn't always good. Linux should cater to the hardware
only to the extent that it makes sense. We don't make design decisions
that are unmaintainable or cripple us in some way because of bad
hardware. That would be stupid.

If we need and want larger IO sizes, then we can do that without big
compound pages. I'm merely interested in the bigger page cache pages
because it'll solve several issues at once.

-- 
Jens Axboe

-
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ