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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
