From: Ingo Molnar <mingo@elte.hu>
To: Eric Dumazet <dada1@cosmosbay.com>
Cc: Ravikiran G Thirumalai <kiran@scalex86.org>,
linux-kernel@vger.kernel.org, shai@scalex86.org,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH] futex: Dynamically size futexes hash table
Date: Sat, 21 Mar 2009 17:28:29 +0100 [thread overview]
Message-ID: <20090321162829.GF11183@elte.hu> (raw)
In-Reply-To: <49C4D5A0.5020106@cosmosbay.com>
* Eric Dumazet <dada1@cosmosbay.com> wrote:
> @@ -2016,7 +2021,28 @@ static int __init futex_init(void)
> {
> u32 curval;
> int i;
> +#if !defined(CONFIG_BASE_SMALL)
> +#if defined(CONFIG_PROVE_LOCKING)
> + unsigned int nb_slots = 256;
> +#else
> + unsigned int nb_slots = roundup_pow_of_two(num_possible_cpus()) * 256;
> +#endif
> + size_t sz;
>
> +retry:
> + sz = nb_slots * sizeof(struct futex_hash_bucket);
> + if (sz > PAGE_SIZE)
> + futex_queues = vmalloc(sz);
> + else
> + futex_queues = kmalloc(sz, GFP_KERNEL);
> + if (!futex_queues) {
> + nb_slots >>= 1;
> + if (!nb_slots)
> + panic("Could not allocate futex hash table");
> + goto retry;
> + }
> + futex_hash_mask = nb_slots - 1;
> +#endif
no fundamental objections and the hash sizing problem is causing
real problems and need to be fixed, but this code sequence is too
ugly to live.
Is there really no big-hash-alloc framework in existence? I have
some vague memories of networking having met such problems in the
past - maybe they have some goodness there we could reuse
shamelessly in the futex code?
Ingo
next prev parent reply other threads:[~2009-03-21 16:29 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 [this message]
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
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=20090321162829.GF11183@elte.hu \
--to=mingo@elte.hu \
--cc=akpm@linux-foundation.org \
--cc=dada1@cosmosbay.com \
--cc=kiran@scalex86.org \
--cc=linux-kernel@vger.kernel.org \
--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