On Tue, 29 Sep 2009, Robin Holt wrote:
>
> If I recall the problems correctly, it is typically a case where a lock
> is held for an extended period of time for "legitimate" reasons. That
> will cause interrupts to be disabled on key cpus for an unusually long
> period of time (cpu 0 has been extremely problematic in holding off
> timers, but I/O targeted interrupts have also caused difficult to diagnose
> erratic I/O patterns).
Sure. But that case has nothing to do with the lock itself - the long
latencies are independent of locking mechanism.
Of course, they'll only happen on _that_ CPU while it is holding the lock,
and ticket locks may end up transferring the latency to other CPU's too
due to having interrupts disabled while waiting, but that doesn't actually
affect the overall bad system latency as much as how often you hit the
latency issue. The ticket locks can certainly cause you to hit it more
often.
On the other hand, the kind of problems we _used_ to have (before ticket
locks) was that even if the long-time holder tried to be nice, and
released the lock for a short while (only to then immediately re-take it),
it wouldn't help other CPU's. The ticket locks help that case: with ticket
locks, you can basically have something like
if (lock_contended(lock)) {
unlock(lock);
lock(lock);
}
that acts as a preemption point, kind of like the "cond_resched()" calls
we have sprinkled around for cases that otherwise might have long preempt
latencies.
Without ticket locks, you can't sanely do the above. With them, it works
(although you'd better have a damn good reason for crap like that).
Linus
--
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
|