Messages in this thread | | | Date | Tue, 06 Apr 2010 19:06:37 +0300 | From | Avi Kivity <> | Subject | Re: [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
| |