On Wed, 4 Jun 2014 17:32:37 +0200 (CEST) Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote: > T3 releases L3 > T2 gets L3 > T2 drops L3 and L2 > T2 blocks on L4 held by T4 > T4 blocked on L5 held by T5 > > So we happily boost T4 and T5. Not what we really want to do. > > Nasty, isn't it ? > Actually, we may go up a chain, but we never do any unnecessary boosting. That's because the boost is done with rt_mutex_adjust_prio() which gets the prio from rt_mutex_getprio() which reads the task->normal_prio and compares it to the task_top_pi_waiter(task)->prio, which will always be correct as we have the necessary locks. And we don't even need to worry about the chain we miss. That is, if task A is blocked on a lock owned by D at the time, but as we go up the chain, D releases the lock and B grabs it, B will still up its priority based on the waiters of the lock (that is A), and if B blocks, it will boost the tasks that own the lock it blocks on, where B is still influenced by A. The fact that we only update the prio based on the actual waiters and don't carry a prio up the chain (which you designed, and I thought was quite ingenious by the way), we may waste time going up a chain, but the priority inheritance is still accurate. -- 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
