From: Ravikiran G Thirumalai <kiran@scalex86.org>
To: Eric Dumazet <dada1@cosmosbay.com>
Cc: linux-kernel@vger.kernel.org, Ingo Molnar <mingo@elte.hu>,
shai@scalex86.org, Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [rfc] [patch 1/2 ] Process private hash tables for private futexes
Date: Mon, 23 Mar 2009 20:19:25 -0700 [thread overview]
Message-ID: <20090324031925.GF7278@localdomain> (raw)
In-Reply-To: <49C805E3.4060808@cosmosbay.com>
On Mon, Mar 23, 2009 at 10:57:55PM +0100, Eric Dumazet wrote:
>Ravikiran G Thirumalai a écrit :
>>
[...]
>> Hmm! How about
>> a) Reduce hash table size for private futex hash and increase hash table
>> size for the global hash?
>>
>> OR, better,
>>
>> b) Since it is multiple spinlocks on the same cacheline which is a PITA
>> here, how about keeping the global table, but just add a dereference
>> to each hash slot, and interleave the adjacent hash buckets between
>> nodes/cpus? So even without needing to lose out memory from padding,
>> we avoid false sharing on cachelines due to unrelated futexes hashing
>> onto adjacent hash buckets?
>>
>
>Because of jhash(), futex slots are almost random. No need to try to interleave
>them. Since you have a "cache line" of 4096 bytes, you need almost 4 pages
>per cpu to avoid in a statistical way false sharing.
How did you come up with that number? So there is no way adjacent
cachelines will never ever be used in the global hash??
next prev parent reply other threads:[~2009-03-24 3:19 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-21 4:46 [rfc] [patch 1/2 ] Process private hash tables for private futexes Ravikiran G Thirumalai
2009-03-21 4:52 ` [rfc] [patch 2/2 ] Sysctl to turn on/off private futex " Ravikiran G Thirumalai
2009-03-21 9:07 ` [rfc] [patch 1/2 ] Process private " Eric Dumazet
2009-03-21 11:55 ` [PATCH] futex: Dynamically size futexes hash table Eric Dumazet
2009-03-21 16:28 ` Ingo Molnar
2009-03-22 4:54 ` [rfc] [patch 1/2 ] Process private hash tables for private futexes Ravikiran G Thirumalai
2009-03-22 8:17 ` Eric Dumazet
2009-03-23 20:28 ` Ravikiran G Thirumalai
2009-03-23 21:57 ` Eric Dumazet
2009-03-24 3:19 ` Ravikiran G Thirumalai [this message]
2009-03-24 3:33 ` Ravikiran G Thirumalai
2009-03-24 5:31 ` Eric Dumazet
2009-03-24 7:04 ` Eric Dumazet
2009-04-23 17:30 ` Darren Hart
2009-03-21 11:35 ` Andrew Morton
2009-03-22 4:15 ` Ravikiran G Thirumalai
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=20090324031925.GF7278@localdomain \
--to=kiran@scalex86.org \
--cc=akpm@linux-foundation.org \
--cc=dada1@cosmosbay.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--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;
as well as URLs for NNTP newsgroup(s).