lkml.org 
[lkml]   [2009]   [Mar]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    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 <kiran@scalex86.org>
    >> Signed-off-by: Shai Fultheim <shai@scalex86.org>
    >>
    >
    >First incantation of PRIVATE_FUTEXES had process private hash table
    >
    >http://lkml.org/lkml/2007/3/15/230
    >
    >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
    >
    >http://lwn.net/Articles/229668/
    >
    >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 :
    >
    >http://linux.derkeiler.com/Mailing-Lists/Kernel/2007-03/msg06504.html
    >
    >[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
    >size)

    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 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/

    \
     
     \ /
      Last update: 2009-03-22 05:57    [W:0.026 / U:1.108 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site