On Fri, 2009-01-09 at 16:06 +0100, Peter Zijlstra wrote: > 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. How about if (!owner && need_resched()) break; instead of the unconditional need_resched(). That should solve the race that Linus saw without and hurt PREEMPT less. > > Adding that blocking on !owner utterly destroys everything. > > Going to look into where that extra preemption comes from. -chris -- 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
