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 toReally? The owner information isn't in general available in the
do the spinning in the kernel where we have all the necessary
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 ?