linux-kernel - Re: [RFC 3/8] Flushing and zeroing higher order page cache pages

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: <20070420165143.GY2986@holomorphy.com>
Date:	Fri, 20 Apr 2007 09:51:43 -0700
From:	William Lee Irwin III <wli@...omorphy.com>
To:	Christoph Lameter <clameter@....com>
Cc:	Mel Gorman <mel@...net.ie>, linux-kernel@...r.kernel.org,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Nick Piggin <nickpiggin@...oo.com.au>, Andi Kleen <ak@...e.de>,
	Paul Jackson <pj@....com>, Dave Chinner <dgc@....com>
Subject: Re: [RFC 3/8] Flushing and zeroing higher order page cache pages

On Fri, 20 Apr 2007, Mel Gorman wrote:
>> While this looks fine, it seems that clear_huge_page() and
>> clear_mapping_page() could share a common helper. I also note that
>> clear_huge_page() calls cond_reched() and this doesn't which may be the
>> type of different behavior we want to avoid.

On Fri, Apr 20, 2007 at 09:15:25AM -0700, Christoph Lameter wrote:
> I am really thinking that this variable order page cache approach 
> is likely going to result in the final death of the huge page subsystem. I 
> would like to keep huge pages separate from this so that the huge page 
> subsystem can be removed at some point without too much trouble. Right now 
> it is a very sore point at least from a performance standpoint since the 
> hugetlb subsystem is serialized with a single lock. There is a weird maze 
> of locking and accounting constraints in there that makes it difficult to 
> fix this.

It'll drive a stake through its heart, but there are a number of stupid
catches to deal with before it'll finally flush down the drain.
Existing apps will require backward compatibility wrappers for various
forms of semantic damage done over the years, some over my objections,
effectively in perpetuity. fs/hugetlbfs/ can effectively be reduced to
wrappers around a normal fs for that, but sadly I doubt the rm -rf I
want will fly barring shoving that crud into fs/ramfs/ (which people
may be loath to do).

On Fri, 20 Apr 2007, Mel Gorman wrote:
>> That said, if this goes ahead, it might be an excuse to look at using
>> ramfs as the basis for hugetlbfs instead of it's current approach. I
>> believe using ramfs for hugepages is something that wli wants anyway.

On Fri, Apr 20, 2007 at 09:15:25AM -0700, Christoph Lameter wrote:
> Right. There is no reason for hugetlbfs to exist anymore. We will have 
> very transparent and flexible support for huge pages.

Ramming hugetlb, fs and all, down the garbage disposal is the direction
I really want to go, and in precisely this manner. (Ever wondered why I
never work on extending it?) There's an easy subdivision of labor here
(apart from where I contribute otherwise). Get generic going and keep
me posted and I'll actively go about ripping out those pieces made
redundant by it all.

To date I've been blocked by the absence of collaborators. I can put
company time down on this vs. other issues which are mere spare time.

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