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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 16 Mar 2007 07:25:53 +1100
From:	Nick Piggin <nickpiggin@...oo.com.au>
To:	Eric Dumazet <dada1@...mosbay.com>
CC:	Ulrich Drepper <drepper@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>, Andi Kleen <ak@...e.de>,
	Ravikiran G Thirumalai <kiran@...lex86.org>,
	"Shai Fultheim (Shai@...lex86.org)" <shai@...lex86.org>,
	pravin b shelar <pravin.shelar@...softinc.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/3] FUTEX : introduce private hashtables

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 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/