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: <20070427235247.3576a463.akpm@linux-foundation.org>
Date:	Fri, 27 Apr 2007 23:52:47 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Christoph Lameter <clameter@....com>
Cc:	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>,
	Nick Piggin <nickpiggin@...oo.com.au>
Subject: Re: [00/17] Large Blocksize Support V3

On Fri, 27 Apr 2007 23:24:05 -0700 (PDT) Christoph Lameter <clameter@....com> wrote:

> > Fact is, this change has *costs*.  And you're completely ignoring them,
> > trying to spin them away.  It ain't working and it never will.  I'm seeing
> > no serious attempt to think about how we can reduce those costs while
> > retaining most of the benefits.
> 
> Well okay my work is "no serious attempt".

No.  My point is, you have resisted all attempts to explore less costly
*alternatives* to this work.  Alternatives.

By misunderstanding any suggestions, misrepresenting them, making incorrect
statements about them, by not suggesting any alternatives yourself, all of
it buttressed by a stolid refusal to recognise that this patch has any
costs.

This effectively leaves it up to others to find time to think about and to
implement possible alternative solutions to the problems which you're
observing.


The altenative which is on the table (and there may be others) is
populating pagecache with physically contiguous pages.  This will fix the
HBA problem and is much less costly in terms of maintenance and will
improve all workloads on all machines and doesn't have the additional
runtime costs of pagecache wastage and more memset() overhead with small
files and it doesn't require administrator intervention.

OTOH (yes!  there are tradeoffs!) it will consume an unknown amount more
CPU and it doesn't address the large-fs-blocksize requirement, but I don't
know how important the latter is and given the unrelenting advocacy storm
coming from the SGI direction I don't know how to find that out, frankly.
-
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