Linus Torvalds wrote:
On Tue, 29 Sep 2009, Linus Torvalds wrote:That may sound like ticket locks are nasty, but there are some upsides. In particular, the fairness of the ticket locks means that latencies are bounded. And just for that simple reason there is often much less reason to worry about having to re-enable interrupts: the bounded upper case is not true of traditional locks.Just to continue on that point: with the old locks on x86, we had test loads that had basically 10,000:1 factors of unfairness, where one CPU would continually get the lock because it was hot in _its_ caches, and all other CPU's would almost always fail.In that situation, re-enabling interrupts can be critical, just because they might be disabled for many thousands of iterations of the spinlock being busy on another CPU.With the ticket locks, you'd need to have a _huge_ machine in order to ever see that kind of situation (ie now you'd need to see thousands of CPU's all trying to get that lock in order to see latencies that are a thousand iterations of whatever happens inside the spinlock). And in practice, with good locking, you should never see that. If you actually have thousands of CPU's (or even hundreds) all wanting the same lock at the same time, you're just going to have to fix the locking.
Doesn't that argument cut both ways? That "good locking" would not have the contention and so the unfairness that was addressed via tickets?
rick jones -- To unsubscribe from this list: send the line "unsubscribe linux-ia64" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|