Messages in this thread | | | Date | Fri, 20 Apr 2007 09:15:25 -0700 (PDT) | From | Christoph Lameter <> | 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |