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