On Wed, 7 May 2008, Ingo Molnar wrote: > > ok, the one below does irq ops and the counter behavior No it doesn't. The counter isn't used for any actual *testing*, so the locking around it and the serialization of it has absolutely no impact on the scheduling behaviour! Since the big slowdown was clearly accompanied by sleeping behaviour (the processes who didn't get the lock end up sleeping!), that is a *big* part of the slowdown. Is it possible that your patch gets similar behaviour? Absolutely. But you're missing the whole point here. Anybody can make code behave badly and perform worse. But if you want to just verify that it's about the sleeping behaviour and timings of the BKL, then you need to do exactly that: emulate the sleeping behavior, not just the timings _outside_ of the sleeping behavior. The thing is, we definitely are interested to see whether it's the BKL or some other semaphore that is the problem. But the best way to test that is to just try my patch that *guarantees* that the BKL doesn't have any semaphore behaviour AT ALL. Could it be something else entirely? Yes. We know it's semaphore- related. We don't know for a fact that it's the BKL itself. There could be other semaphores that are that hot. It sounds unlikely, but quite frankly, regardless, I don't really see the point of your patches. If Yanmin tries my patch, it is *guaranteed* to show something. It either shows that it's about the BKL (and that we absolutely have to do the BKL as something _else_ than a generic semaphore), or it shows that it's not about the BKL (and that _all_ the patches in this discussion are likely pointless). In contrast, these "try to emulate bad behavior with the old known-ok semaphores" don't show anything AT ALL. We already know it's related to semaphores. And your patches aren't even guaranteed to show the same issue. Linus -- 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