mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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

  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®