From: Ingo Molnar <mingo@elte.hu>
To: Pierre Peiffer <pierre.peiffer@bull.net>
Cc: LKML <linux-kernel@vger.kernel.org>,
"Dinakar Guniguntala" <dino@in.ibm.com>,
"Jean-Pierre Dion" <jean-pierre.dion@bull.net>,
"Sébastien Dugué" <sebastien.dugue@bull.net>,
"Ulrich Drepper" <drepper@redhat.com>,
"Darren Hart" <dvhltc@us.ibm.com>,
"Jakub Jelinek" <jakub@redhat.com>
Subject: Re: [PATCH 2.6.19-rt12][RFC] - futex_requeue_pi implementation (requeue from futex1 to PI-futex2)
Date: Wed, 13 Dec 2006 18:54:05 +0100 [thread overview]
Message-ID: <20061213175405.GB32441@elte.hu> (raw)
In-Reply-To: <45801FA4.8040403@bull.net>
* Pierre Peiffer <pierre.peiffer@bull.net> wrote:
> With the introduction of the PI-futex (used for the PI-pthread_mutex
> in the glibc), the current futex_requeue optimization (*) can not be
> used any more if the pthread_mutex used with the pthread-condvar is a
> PI-mutex.
>
> (*) this optimization is used in pthread_cond_broadcast.
>
> To use this optimization with PI-mutex, we need a function that
> re-queues some threads from a normal futex to a PI-futex (see why in
> this discussion:
> http://marc.theaimsgroup.com/?l=linux-kernel&m=115020355126851&w=2 )
>
> Here is a proposal of an implementation of futex_requeue_pi.
> (Only the 32-bits version has been implemented for now)
the kernel patch looks straightforward and desirable to me. (modulo some
minor style-nitpicking observations below.) I'd suggest to implement the
64-bit and compat versions too, unless Jakub can see a hole in the
concept or in the implementation.
> -#define FUTEX_TID_MASK 0x3fffffff
> +#define FUTEX_TID_MASK 0x1fffffff
ABI change but tthis should be fine i think ... right now we dont let
PIDs go above 0xffff anyway. It might make sense to lower it to
0x0fffffff, to have one more bit in that word ... just in case.
> + /* This waiter is used in case of requeue from a
> + normal futex to a PI-futex */
please use proper comment style.
> + if (key->both.offset & 1)
> + /* shared mapping */
> + uaddr = (void*)((key->shared.pgoff << PAGE_SHIFT)
> + + key->shared.offset - 1);
> + else
> + /* private mapping */
> + uaddr = (void*)(key->private.address + key->private.offset);
such multi-line branches need curly braces.
> +static inline int lookup_pi_state_for_requeue(u32 __user *uaddr,
> + struct futex_hash_bucket *hb,
> + union futex_key *key,
> + struct futex_pi_state
> **pi_state)
patch line wrap problem? Also, if the function name is so long, you can
do:
static inline int
lookup_pi_state_for_requeue(u32 __user *uaddr, struct futex_hash_bucket *hb,
Ingo
next prev parent reply other threads:[~2006-12-13 17:56 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-13 15:43 Pierre Peiffer
2006-12-13 17:54 ` Ingo Molnar [this message]
[not found] <458003BD.40705@bull.net>
2006-12-13 15:45 ` Pierre Peiffer
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=20061213175405.GB32441@elte.hu \
--to=mingo@elte.hu \
--cc=dino@in.ibm.com \
--cc=drepper@redhat.com \
--cc=dvhltc@us.ibm.com \
--cc=jakub@redhat.com \
--cc=jean-pierre.dion@bull.net \
--cc=linux-kernel@vger.kernel.org \
--cc=pierre.peiffer@bull.net \
--cc=sebastien.dugue@bull.net \
/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
all inboxes | Powered by JetHome®