Re: [PATCH 2/3] FUTEX : introduce private hashtables

[Nick Piggin <nickpiggin@yahoo.com.au>]

Eric Dumazet wrote:
> [PATCH 2/3] FUTEX : introduce private hashtables
> 
> This patch introduces a separate hashtable per process to store _PRIVATE 
> futexes.
> This hashtable is dynamically allocated on the first _PRIVATE futex syscall.
> If memory cannot be allocated, the process will use the global hashtable.
> 
> Using a separate hashtable has the advantage of lowering the contention on the 
> global hashtable. NUMA should benefits of this separation because the 
> allocation should respect the mm policy of the process.
> 
> Code is using kmalloc()/vmalloc() depending on the size of spinlocks. For 
> normal setup, size of the private hashtable should be 768 bytes on 32bit 
> arches, 1536 bytes on 64bit arches.
> 
> Private hashtable is freed() when process exits.


I do disagree with this patch, though.

There should be little contention on the memory in the global hash anyway,
because we can roughly reduce contention as a factor of hash-size/cacheline-size.

What we will have are cache misses on the global table... but we're going to
get cache misses on those private tables as well. Also, you never know what
the use cases are going to be... there could be an application with thousands
of threads and mutexes in which case your private hash could be too small... I
think w e want to stay away from per-mm _anything_ with private futexes, which
is the direction that your patch 1 takes us.

I would just avoid the complexity and setup/teardown costs, and just use a
vmalloc'ed global hash for NUMA.

-- 
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com