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

[Avi Kivity]

On 04/06/2010 06:28 PM, Darren Hart wrote:
> Alan Cox wrote:
> > On Tue, 06 Apr 2010 15:35:31 +0200
> > Peter Zijlstra <peterz@xxxxxxxxxxxxx> 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.
> >
> > Thats a gross and inaccurate simplification. For the case Avi is talking
> > about spinning in userspace makes sense in a lot of environments. Once
> > you've got one thread pinned per cpu (or gang scheduling >-) ) there are
> > various environments where it makes complete and utter sense.
>
> Hi Alan,
>
> Do you feel some of these situations would also benefit from some 
> kernel assistance to stop spinning when the owner schedules out? Or 
> are you saying that there are situations where pure userspace 
> spinlocks will always be the best option?
>
> If the latter, I'd think that they would also be situations where 
> sched_yield() is not used as part of the spin loop. If so, then these 
> are not our target situations for FUTEX_LOCK_ADAPTIVE, which hopes to 
> provide a better informed mechanism for making spin or sleep 
> decisions. If sleeping isn't part of the locking construct 
> implementation, then FUTEX_LOCK_ADAPTIVE doesn't have much to offer.

IMO the best solution is to spin in userspace while the lock holder is 
running, fall into the kernel when it is scheduled out.

--
error compiling committee.c: too many arguments to function

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/