On Thu, 8 Mar 2012, Steven Rostedt wrote: > On Thu, 2012-03-08 at 22:20 +0100, Peter Zijlstra wrote: > > > Now put the thing on 2 cpus and both tasks can endlessly chase each > > other's tail, no? > > How would this be different than what mainline does? When the lock is > released, it will wake up the other task. Nonsense. That code is not causing any headache in mainline simply because the lock holder cannot be preempted. So the contention case runs on different cpus. On RT the failure case is when the trylocker preempts the lock holder, which cannot be moved to a different cpu due to the implicit migrate disable. Aside of that cpu_relax() and ticket locks are there for a reason. They allow the other cpu to make progress instead of allowing the trylocking cpu to monopolize the cache line forever. The only case where mainline can fail is when a high prio task does a mutex_trylock() loop and the mutex owner and the trylocker are pinned on the same core. Though I have not yet found code like that, but I have not looked too hard either :) It's a simple RT problem, which has been there forever, but obviously nobody did stress tests such code pathes on UP systems or if someone did he was not able to trigger it. On SMP this was not a big issue when task migration was almost always enabled. Due to the implicit migrate disable withing spinlocked regions we just made it more likely to happen. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
