[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20070421151830.4edb54ae.akpm@linux-foundation.org>
Date: Sat, 21 Apr 2007 15:18:30 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: David Chinner <dgc@....com>
Cc: Jens Axboe <jens.axboe@...cle.com>,
Christoph Lameter <clameter@....com>,
linux-kernel@...r.kernel.org,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Nick Piggin <nickpiggin@...oo.com.au>,
Paul Jackson <pj@....com>, Andi Kleen <ak@...e.de>
Subject: Re: [RFC 0/8] Variable Order Page Cache
On Fri, 20 Apr 2007 17:48:18 +1000 David Chinner <dgc@....com> wrote:
> Agreed - I was talking about a quick way to hack a real filesystem
> in to the VM to start exercising the new VM code without needing to
> implement compound page support down the whole I/O stack.
Yes. The whole point of this work is to speed stuff up, so I'd encourage
people to first work on getting some minimal scruffy proptotype in place -
whatever is needed to be able to start running performance tests.
Then we can take a look at the numbers (and the types of machines and
workloads upon which they are based) and decide whether it looks like
there's any point in proceeding with a full-on implementation.
And as part of that decision-making process we should take a detailed look
at the performance of the existing code and see if there are other ways in
which it might be acceptably sped up.
Because right now we're assuming that larger pages are the only way in
which acceptable performance may be obtained. But that has not been proved.
-
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