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

[Christoph Lameter <clameter@sgi.com>]

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/