When calling set_task_cpu(), we must update both runqueue clocks in order
to get an accurate clock offset. Add it.
Signed-off-by: Mike Galbraith <efa...@gmx.de>
Cc: Ingo Molnar <mi...@elte.hu>
Cc: Peter Zijlstra <a.p.zi...@chello.nl>
LKML-Reference: <new-submission>
---
kernel/sched.c | 1 +
1 file changed, 1 insertion(+)
Index: linux-2.6/kernel/sched.c
===================================================================
--- linux-2.6.orig/kernel/sched.c
+++ linux-2.6/kernel/sched.c
@@ -2126,6 +2126,7 @@ migrate_task(struct task_struct *p, int
*/
if (!p->se.on_rq && !task_running(rq, p)) {
update_rq_clock(rq);
+ update_rq_clock(cpu_rq(dest_cpu));
set_task_cpu(p, dest_cpu);
return 0;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
We should make double_rq_lock() and double_lock_balance() behave
equivalent wrt update_rq_clock().
Current, depending on CONFIG_PREEMPT, double_lock_balance() already
updates both rq clocks.
> We should make double_rq_lock() and double_lock_balance() behave
> equivalent wrt update_rq_clock().
>
> Current, depending on CONFIG_PREEMPT, double_lock_balance() already
> updates both rq clocks.
Hm, right. Better plan. We can save an update in the wakeup path for
the tasks racing for the wakeup case too. If the call is really a
lock/unlock go away, we don't need to bother. Shave a ns or so.
-Mike
Oops, nope. Consistency is still a good plan, however, that update is
still needed, because it's the case where we're _not_ going to use the
migration thread.