[lkml]   [2011]   [Jul]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 2/2] hugepage: Allow parallelization of the hugepage fault path

    Hi Mel,

    > I haven't tested this patch yet but typically how I would test it is
    > multiple parallel instances of make func from libhugetlbfs. In
    > particular I would be looking out for counter corruption. Has
    > something like this been done? I know hugetlb_lock protects the
    > counters but the locking in there has turned into a bit of a mess so
    > it's easy to miss something.

    Thanks for the suggestion and sorry for taking so long. Make check has
    the same PASS/FAIL count before and after the patches.

    I also ran 16 copies of make func on a large box with 896 HW threads.
    Some of the tests that use shared memory were a bit upset, but that
    seems to be because we use a static key. It seems the tests were also
    fighting over the number of huge pages they wanted the system set to.

    It got up to a load average of 13207, and heap-overflow consumed all my
    memory, a pretty good effort considering I have over 1TB of it.

    After things settled down things were OK, apart from the fact that we
    have 20 huge pages unaccounted for:

    HugePages_Total: 10000
    HugePages_Free: 9980
    HugePages_Rsvd: 0
    HugePages_Surp: 0

    I verified there were no shared memory segments, and no files in the
    hugetlbfs filesystem (I double checked by unmounting it).

    I can't see how this patch set would cause this. It seems like we can
    leak huge pages, perhaps in an error path. Anyway, I'll repost the
    patch set for comments.


     \ /
      Last update: 2011-07-15 08:09    [W:0.051 / U:14.068 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site