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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.64.0704200910440.20232@schroedinger.engr.sgi.com>
Date:	Fri, 20 Apr 2007 09:15:25 -0700 (PDT)
From:	Christoph Lameter <clameter@....com>
To:	Mel Gorman <mel@...net.ie>
cc:	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.

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.

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

Right. There is no reason for hugetlbfs to exist anymore. We will have 
very transparent and flexible support for huge pages.
-
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/