Hi Ingo, Thomas, this one-liner fixes a bug in balance_rt_tasks() which sometimes manifests by having a lower prio task being scheduled while a higher prio task is sitting waiting on another runqueue. This is pretty hard to reproduce on low cpu count machines, for example, I had to have sched_football run in a loop for ~38h before it failed on a dual HT Xeon box. Sébastien. --- In the CPU loop in balance_rt_tasks(), the 'next' task pointer is only ever updated if this_rq->lock has been dropped in double_lock_balance(). This sometimes lead to 'this_cpu' pulling tasks that are only garanteed to have a higher priority than the 'next' picked before the loop. Fix this to update 'next' to the last picked RT task. Signed-off-by: Sébastien Dugué <sebastien.dugue@xxxxxxxx> --- kernel/sched.c | 8 ++++++++ 1 file changed, 8 insertions(+) Index: linux-2.6.22.1-rt6/kernel/sched.c =================================================================== --- linux-2.6.22.1-rt6.orig/kernel/sched.c 2007-07-24 11:34:18.000000000 +0200 +++ linux-2.6.22.1-rt6/kernel/sched.c 2007-07-24 11:34:35.000000000 +0200 @@ -1499,6 +1499,14 @@ static void balance_rt_tasks(struct rq * * in another runqueue. (low likelyhood * but possible) */ + + /* + * Update next so that we won't pick a task + * on another cpu with a priority lower (or equal) + * than the one we just picked. + */ + next = p; + } spin_unlock(&src_rq->lock); } - 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
