Re: [PATCH V2 0/6][RFC] futex: FUTEX_LOCK with optional adaptivespinning

From: Darren Hart
Date: Tue Apr 06 2010 - 19:36:52 EST

Thomas Gleixner wrote:
On Tue, 6 Apr 2010, Ulrich Drepper wrote:

On Tue, Apr 6, 2010 at 12:31, Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote:
We need to figure out a more efficient way to
do the spinning in the kernel where we have all the necessary
information already.
Really? The owner information isn't in general available in the
kernel. Futex operation doesn't require the value used to be the PID
(or negative of the PID). That is a dramatic limitation of the
usefulness of futexes.

I know that you can do any weird stuff with the futex value, but I
don't see the "dramatic" limitation. Care to elaborate ?

At userlevel there is access to other fields of the data structure
which can contain the owner information.

I would like to see the method using a per-thread pinned page and an
update of a memory location on scheduling. For benchmarking at least.

The per thread pinned page would be unconditional, right ?

I agree that benchmarking would be interesting, but OTOH I fear that
we open up a huge can of worms with exposing scheduler details and the
related necessary syscalls like sys_yield_to: User space thread
management/scheduling comes to my mind and I hope we agree that we do
not want to revisit that.

I agree that a sys_yield_to() syscall would be at the very least
useful as well. But it's useful for other things already.

Useful for what ?

What are the exact semantics of such a syscall ?

How does that fit into the various scheduling constraints ?

I believe this comes back to the discussions of a directed yield. The idea being that a thread yields its remaining timeslice to a thread of it's choosing - usually because the target thread holds a resource the yielding thread needs access to. This makes the yield more explicit so the yielding thread is more likely to get some benefit out of yielding.

I believe the arguments would be either a TID or a thread group - however that is specified. I believe the KVM guys would like to see something like this as well - which might be the "other things" referred to above.

Darren Hart
IBM Linux Technology Center
Real-Time Linux Team
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at