[lkml]   [2007]   [Apr]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [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
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-04-20 18:17    [W:0.019 / U:15.464 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site