On Thu, 2012-03-08 at 22:37 +0100, Peter Zijlstra wrote: > > Now when the original task releases the lock again, the other task can > > take it just like it does on mainline. > > Now interleave it with a third task of even higher priority that puts > the spinner to sleep. So? It will eventually have to allow the task to run. Adding a "third higher priority" task can cause problems in any other part of the -rt kernel. We don't need to worry about priority inversion. If the higher task blocks on the original task, it will boost its priority (even if it does the adaptive spin) which will again boost the task that it preempted. Now we may need to add a sched_yield() in the adaptive spin to let the other task run. -- Steve -- 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