Messages in this thread | | | Subject | Re: [PATCH -v7][RFC]: mutex: implement adaptive spinning | From | Peter Zijlstra <> | Date | Fri, 09 Jan 2009 16:06:54 +0100 |
| |
On Fri, 2009-01-09 at 11:47 +0100, Peter Zijlstra wrote:
> > So I think the bug is still there, we just hid it better by breaking out > > of the loop with that "if (need_resched())" always eventually triggering. > > And it would be ok if it really is guaranteed to _eventually_ trigger, and > > I guess with timeslices it eventually always will, but I suspect we could > > have some serious latency spikes. > > Yes, the owner getting preempted after acquiring the lock, but before > setting the owner can give some nasties :-( > > I initially did that preempt_disable/enable around the fast path, but I > agree that slowing down the fast path is unwelcome. > > Alternatively we could go back to block on !owner, with the added > complexity of not breaking out of the spin on lock->owner != owner > when !lock->owner, so that the premature owner clearing of the unlock > fast path will not force a schedule right before we get a chance to > acquire the lock. > > Let me do that..
Ok a few observations..
Adding that need_resched() in the outer loop utterly destroys the performance gain for PREEMPT=y. Voluntary preemption is mostly good, but somewhat unstable results.
Adding that blocking on !owner utterly destroys everything.
Going to look into where that extra preemption comes from.
| |