[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <45F9BAA1.9040803@yahoo.com.au>
Date: Fri, 16 Mar 2007 08:29:05 +1100
From: Nick Piggin <nickpiggin@...oo.com.au>
To: Ulrich Drepper <drepper@...il.com>
CC: Eric Dumazet <dada1@...mosbay.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
Ulrich Drepper wrote:
> On 3/15/07, Nick Piggin <nickpiggin@...oo.com.au> wrote:
>
>> 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.
>
>
> I'm thinking about NUMA cases. If you have private tables for a
> process which is pinned to some cluster in a NUMA machine the table is
> local to the node. If you have a global table you cannot optimize
> your application for such a situation because at least some of the
> pages of the global table are remote.
>
That's true, but it also might be able to be improved in other ways.
At least once we get the basic support in the kernel, and glibc picks
it up, then we have a better base to evaluate these more exotic changes
against.
--
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/
Powered by blists - more mailing lists