linux-kernel - Re: [RFC 0/8] Variable Order Page Cache

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]

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/