Messages in this thread | ![/](/images/icornerl.gif) | | Date | Tue, 06 Apr 2010 19:10:23 +0300 | From | Avi Kivity <> | Subject | Re: [PATCH V2 0/6][RFC] futex: FUTEX_LOCK with optional adaptive spinning |
| |
On 04/06/2010 05:09 PM, Peter Zijlstra wrote: > On Tue, 2010-04-06 at 16:41 +0300, Avi Kivity wrote: > >> On 04/06/2010 04:35 PM, Peter Zijlstra wrote: >> >>> On Tue, 2010-04-06 at 16:28 +0300, Avi Kivity wrote: >>> >>> >>>> Yes, but that's the best case for spinning. You could simply use a >>>> userspace spinlock in this case. >>>> >>>> >>> Userspace spinlocks are evil.. they should _never_ be used. >>> >>> >> But in this case they're fastest. If we don't provide a non-evil >> alternative, people will use them. >> >> > That's what FUTEX_LOCK is about. >
That works for the uncontended case. For the contended case, the waiter and the owner have to go into the kernel and back out to transfer ownership. In the non-adaptive case you have to switch to the idle task and back as well, and send an IPI. That's a lot of latency if the unlock happened just after the waiter started the descent into the kernel.
-- error compiling committee.c: too many arguments to function
| ![\](/images/icornerr.gif) |