[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <m17irzkm8q.fsf@ebiederm.dsl.xmission.com>
Date: Thu, 26 Apr 2007 12:45:57 -0600
From: ebiederm@...ssion.com (Eric W. Biederman)
To: Christoph Lameter <clameter@....com>
Cc: David Chinner <dgc@....com>, Nick Piggin <nickpiggin@...oo.com.au>,
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>
Subject: Re: [00/17] Large Blocksize Support V3
Christoph Lameter <clameter@....com> writes:
> On Thu, 26 Apr 2007, Eric W. Biederman wrote:
>> The change the fundamental fragmentation avoidance algorithm of the
>> OS. Use only one size of page. That is a huge problem.
>
> No its no problem at all. Its in some peoples head that have never seen it
> done otherwise. We have another OS here that has dealt with variable sized
> pages for ages and our people have been shaking their heads for years
> about these strong opinious that lead us not dealing with the
> problem.
If you can make small things go fast, everything speeds up.
If you can only make big things go fast only some things speed up.
I want to make small things go fast so everything speeds up.
This isn't whatever OS you are used to dealing with. Assumptions are
different, and improving streaming read/writes benchmarks are not our
focus.
One of the first rules in storage or OS design is that it better be
reliable, and you patch looks like it will make the VM unreliable. So
no a design like this will not be agreed to without comment until it
is shown that the VM does not have problems.
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/
Powered by blists - more mailing lists