[lkml]   [2006]   [Mar]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    Patch in this message
    SubjectRE: [patch] hugetlb strict commit accounting
    David Gibson wrote on Thursday, March 09, 2006 3:27 AM
    > Again, there are no changes to the fault handler. Including the
    > promised changes which would mean my instantiation serialization path
    > isn't necessary ;-).

    This is the major portion that I omitted in the first patch and is the
    real kicker that fulfills the promise of guaranteed available hugetlb
    page for shared mapping.

    You can shower me all over on the lock protection :-) yes, this is not
    perfect and was the reason I did not post it earlier, but I want to give
    you the concept on how I envision this route would work.

    Again PRIVATE mapping is busted, you can't count them from inode. You
    would have to count them via mm_struct (I think).

    - Ken

    Note: definition of "reservation" in earlier patch is total hugetlb pages
    needed for that file, including the one that is already faulted in. Maybe
    that throw you off a bit because I'm guessing your definition is "needed
    in the future" and probably you are looking for a decrement of the counter
    in the fault path?

    --- ./mm/hugetlb.c.orig 2006-03-09 04:46:38.965547435 -0800
    +++ ./mm/hugetlb.c 2006-03-09 04:48:20.804413375 -0800
    @@ -196,6 +196,8 @@ static unsigned long set_max_huge_pages(
    + if (count < atomic_read(&resv_huge_pages))
    + count = atomic_read(&resv_huge_pages);
    if (count >= nr_huge_pages)
    return nr_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: 2006-03-09 13:06    [W:0.021 / U:6.284 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site