* Pierre Peiffer <[email protected]> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
