[lkml]   [2009]   [Mar]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [rfc] [patch 1/2 ] Process private hash tables for private futexes
    On Sat, Mar 21, 2009 at 10:07:48AM +0100, Eric Dumazet wrote:
    >Ravikiran G Thirumalai a écrit :
    >> We found this patch to improve the runtime of a certain FEA solver by about
    >> 15% on a 32 core vSMP system.
    >> Signed-off-by: Ravikiran Thirumalai <>
    >> Signed-off-by: Shai Fultheim <>
    >First incantation of PRIVATE_FUTEXES had process private hash table
    >I dont remember objections at that time, maybe it was going to slow down small
    >users of these PRIVATE_FUTEXES, ie processes that will maybe use one futex_wait()
    > in their existence, because they'll have to allocate their private hash table
    >and populate it.

    With the current proposal, we can still use the global futex hashes for such
    workloads (with the sysctl setting).

    >So I dropped parts about NUMA and private hash tables to get PRIVATE_FUTEXES into mainline
    >Did you tried to change FUTEX_HASHBITS instead, since current value is really really
    >ridiculous ?

    We tried it in the past and I remember on a 16 core machine, we had to
    use 32k hash slots to avoid false sharing.

    >You could also try to adapt this patch to current kernels :
    >[PATCH 3/3] FUTEX : NUMA friendly global hashtable
    >On NUMA machines, we should get better performance using a big futex
    >hashtable, allocated with vmalloc() so that it is spreaded on several nodes.
    >I chose a static size of four pages. (Very big NUMA machines have 64k page

    Yes, dynamically changing the hash table is better (looking at the patch you
    have posted), but still there are no locality guarantees here. A process
    pinned to node X may still end up accessing remote memory locations while
    accessing the hash table. A process private table on the other hand should
    not have this problem. I think using a global hash for entirely process local
    objects is bad design wise here.
    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: 2009-03-22 05:57    [W:0.039 / U:42.440 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site