From: Ravikiran G Thirumalai <kiran@scalex86.org>
To: Eric Dumazet <dada1@cosmosbay.com>
Cc: Andi Kleen <ak@suse.de>,
"Shai Fultheim (Shai@scalex86.org)" <shai@scalex86.org>,
pravin b shelar <pravin.shelar@calsoftinc.com>,
linux-kernel@vger.kernel.org
Subject: Re: [RFC] NUMA futex hashing
Date: Tue, 8 Aug 2006 17:13:03 -0700 [thread overview]
Message-ID: <20060809001303.GB3762@localhost.localdomain> (raw)
In-Reply-To: <200608081210.40334.dada1@cosmosbay.com>
On Tue, Aug 08, 2006 at 12:10:39PM +0200, Eric Dumazet wrote:
> On Tuesday 08 August 2006 11:57, Andi Kleen wrote:
> > Ravikiran G Thirumalai <kiran@scalex86.org> writes:
> > > Current futex hash scheme is not the best for NUMA. The futex hash
> > > table is an array of struct futex_hash_bucket, which is just a spinlock
> > > and a list_head -- this means multiple spinlocks on the same cacheline
> > > and on NUMA machines, on the same internode cacheline. If futexes of two
> > > unrelated threads running on two different nodes happen to hash onto
> > > adjacent hash buckets, or buckets on the same internode cacheline, then
> > > we have the internode cacheline bouncing between nodes.
> >
> > When I did some testing with a (arguably far too lock intensive) benchmark
> > on a bigger box I got most bouncing cycles not in the futex locks itself,
> > but in the down_read on the mm semaphore.
>
> This is true, even with a normal application (not a biased benchmark) and
> using oprofile. mmap_sem is the killer.
Not if two threads of two different process (so no same mmap_sem) hash onto
futexes on the same cacheline. But agreed, mmap_sem needs to be fixed too.
If everyone agrees on a per-process hash table for private futexes, then
we will work on that approach.
Thanks,
Kiran
prev parent reply other threads:[~2006-08-09 0:11 UTC|newest]
Thread overview: 78+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-08 7:07 [RFC] NUMA futex hashing Ravikiran G Thirumalai
2006-08-08 9:14 ` Eric Dumazet
2006-08-08 20:31 ` Ravikiran G Thirumalai
2006-08-08 9:37 ` Jes Sorensen
2006-08-08 9:58 ` Andi Kleen
2006-08-08 10:07 ` Jes Sorensen
2006-08-08 9:57 ` Andi Kleen
2006-08-08 10:10 ` Eric Dumazet
2006-08-08 10:36 ` Andi Kleen
2006-08-08 12:29 ` Eric Dumazet
2006-08-08 12:47 ` Andi Kleen
2006-08-08 12:57 ` Eric Dumazet
2006-08-08 14:39 ` Ulrich Drepper
2006-08-08 15:11 ` Nick Piggin
2006-08-08 15:36 ` Ulrich Drepper
2006-08-08 16:22 ` Nick Piggin
2006-08-08 16:26 ` Nick Piggin
2006-08-08 16:49 ` Ulrich Drepper
2006-08-08 16:08 ` Eric Dumazet
2006-08-08 16:34 ` Nick Piggin
2006-08-08 16:49 ` Eric Dumazet
2006-08-08 16:59 ` Eric Dumazet
2006-08-09 1:56 ` Nick Piggin
2006-08-08 16:58 ` Ulrich Drepper
2006-08-08 17:08 ` Eric Dumazet
2006-08-09 1:58 ` Nick Piggin
2006-08-09 6:26 ` Eric Dumazet
2006-08-09 6:43 ` Eric Dumazet
2007-03-15 19:10 ` [PATCH 0/3] FUTEX : new PRIVATE futexes, SMP and NUMA improvements Eric Dumazet
2007-03-15 20:15 ` Nick Piggin
2007-03-16 8:05 ` Peter Zijlstra
2007-03-16 9:30 ` Eric Dumazet
2007-03-16 10:10 ` Peter Zijlstra
2007-03-16 10:30 ` Eric Dumazet
2007-03-16 10:36 ` Peter Zijlstra
2007-04-04 7:16 ` Ulrich Drepper
2007-04-05 17:49 ` [PATCH] FUTEX : new PRIVATE futexes Eric Dumazet
2007-04-05 20:43 ` Ulrich Drepper
2007-04-06 1:19 ` Nick Piggin
2007-04-06 5:53 ` Eric Dumazet
2007-04-06 11:50 ` Nick Piggin
2007-04-06 6:05 ` Hugh Dickins
2007-04-06 17:41 ` Jan Engelhardt
2007-04-06 12:26 ` Shared futexes (was [PATCH] FUTEX : new PRIVATE futexes) Peter Zijlstra
2007-04-06 13:02 ` Hugh Dickins
2007-04-06 13:15 ` Peter Zijlstra
2007-04-06 13:15 ` Nick Piggin
2007-04-06 13:22 ` Peter Zijlstra
2007-04-06 13:40 ` Nick Piggin
2007-04-06 12:31 ` [PATCH] FUTEX : new PRIVATE futexes Peter Zijlstra
2007-04-07 8:43 ` [PATCH, take4] " Eric Dumazet
2007-04-07 9:30 ` Nick Piggin
2007-04-07 10:00 ` Eric Dumazet
2007-04-11 7:22 ` Nick Piggin
2007-04-11 8:14 ` Eric Dumazet
2007-04-11 9:23 ` Nick Piggin
2007-04-11 9:30 ` Pierre Peiffer
2007-04-11 9:39 ` Nick Piggin
2007-04-11 9:40 ` Nick Piggin
2007-04-11 9:35 ` Eric Dumazet
2007-04-12 1:57 ` Nick Piggin
2007-04-07 11:18 ` Jakub Jelinek
2007-04-07 11:54 ` Eric Dumazet
2007-04-07 16:40 ` Ulrich Drepper
2007-04-07 22:15 ` Andrew Morton
2007-04-10 9:21 ` Eric Dumazet
2007-04-11 9:19 ` [PATCH, take5] " Eric Dumazet
2007-04-11 12:23 ` Rusty Russell
2007-04-26 12:55 ` [PATCH, take6] " Eric Dumazet
2007-04-26 13:35 ` Pierre Peiffer
2007-03-15 19:13 ` [PATCH 1/3] FUTEX : introduce PROCESS_PRIVATE semantic Eric Dumazet
2007-03-15 19:16 ` [PATCH 2/3] FUTEX : introduce private hashtables Eric Dumazet
2007-03-15 20:25 ` Nick Piggin
2007-03-15 21:09 ` Ulrich Drepper
2007-03-15 21:29 ` Nick Piggin
2007-03-15 22:59 ` William Lee Irwin III
2007-03-15 19:20 ` [PATCH 3/3] FUTEX : NUMA friendly global hashtable Eric Dumazet
2006-08-09 0:13 ` Ravikiran G Thirumalai [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060809001303.GB3762@localhost.localdomain \
--to=kiran@scalex86.org \
--cc=ak@suse.de \
--cc=dada1@cosmosbay.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pravin.shelar@calsoftinc.com \
--cc=shai@scalex86.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox