Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[patch] sched: add the other missing clock update to migrate_task()

3 views
Skip to first unread message

Mike Galbraith

unread,
Nov 22, 2009, 7:20:02 AM11/22/09
to

sched: add the other missing clock update to migrate_task()

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/

Peter Zijlstra

unread,
Nov 22, 2009, 8:20:02 AM11/22/09
to
On Sun, 2009-11-22 at 13:11 +0100, Mike Galbraith wrote:
> sched: add the other missing clock update to migrate_task()
>
> 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;
> }


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.

Mike Galbraith

unread,
Nov 22, 2009, 12:00:03 PM11/22/09
to
On Sun, 2009-11-22 at 14:16 +0100, Peter Zijlstra wrote:

> 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

Mike Galbraith

unread,
Nov 22, 2009, 1:20:03 PM11/22/09
to
On Sun, 2009-11-22 at 17:58 +0100, Mike Galbraith wrote:
> On Sun, 2009-11-22 at 14:16 +0100, Peter Zijlstra wrote:
>
> > 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.

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.

0 new messages