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]

Message-ID: <Pine.LNX.4.64.0704192220510.16360@schroedinger.engr.sgi.com>
Date:	Thu, 19 Apr 2007 22:27:34 -0700 (PDT)
From:	Christoph Lameter <clameter@....com>
To:	William Lee Irwin III <wli@...omorphy.com>
cc:	linux-kernel@...r.kernel.org,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Nick Piggin <nickpiggin@...oo.com.au>,
	Paul Jackson <pj@....com>, Dave Chinner <dgc@....com>,
	Andi Kleen <ak@...e.de>
Subject: Re: [RFC 0/8] Variable Order Page Cache

On Thu, 19 Apr 2007, William Lee Irwin III wrote:

> Oh dear. Per-file pagesizes are foul. Better to fix up the pagecache's
> radix tree than to restrict it like this. There are other attacks on the
> multiple horizontal internal tree node allocation problem beyond
> outright B+ trees that allow radix trees to continue to be used.

per-file pagesizes are just the granularity that is available. The order
value is then readily available for all page cache operations. In practice 
it is likely that filesystems will have one consistent page size. If you 
look at the ramfs implementation then you will see that is exactly the
approach taken here. I want to avoid any modifications to key data 
structures or locking. If possible straight code transformation.

> I've always wanted the awareness to be pervasive, so it's good to hear
> there's someone with a common interest. If this effort takes off, I'd be
> happy to contribute to it. I do wonder what ever happened with the gelato
> codebase, though.

The superpages? I do not think that we should be getting that complicated 
here. Maybe we can pick up some ideas at some point.

> > since we are always operating on a single page struct. Reclaim is fooled to
> > think that it is touching page sized objects (there are likely issues to be
> > fixed there if we want to go down this road).
> 
> I'm afraid this may be approaching an underappreciated research topic.
> Most sponsors of such research seem to have an active disinterest in
> getting page replacement to properly interoperate with all this.

Well that is the difference between academia where one gets his Ph.D. for
superpages, publishes a couple of papers and then its over and real 
kernel work where this actually will have to work consistently with the 
rest of the system. Let us thus do small steps towards the goal 
while keeping things as simple and straightforward as possible.

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