lkml.org 
[lkml]   [2010]   [Apr]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH V2 0/6][RFC] futex: FUTEX_LOCK with optional adaptive spinning
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@infradead.org> 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



\
 
 \ /
  Last update: 2010-04-06 18:09    [W:0.331 / U:0.044 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site