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. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
