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é <[email protected]>
---
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-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
