From: Mike Galbraith <efault@gmx.de>
To: "Bjoern B. Brandenburg" <bbb.lst@gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@elte.hu>,
Andrea Bastoni <bastoni@sprg.uniroma2.it>,
"James H. Anderson" <anderson@cs.unc.edu>,
linux-kernel@vger.kernel.org
Subject: Re: Scheduler bug related to rq->skip_clock_update?
Date: Sun, 21 Nov 2010 10:14:01 -0700 [thread overview]
Message-ID: <1290359641.4816.69.camel@maggy.simson.net> (raw)
In-Reply-To: <alpine.LNX.2.00.1011202315290.8927@jupiter-cs.cs.unc.edu>
On Sat, 2010-11-20 at 23:22 -0500, Bjoern B. Brandenburg wrote:
> I was under the impression that, as an invariant, tasks should not have
> TIF_NEED_RESCHED set after they've blocked. In this case, the idle load
> balancer should not mark the task that's on its way out with
> set_tsk_need_resched().
Nice find.
> In any case, check_preempt_curr() seems to assume that a resuming task cannot
> have TIF_NEED_RESCHED already set. Setting skip_clock_update on a remote CPU
> that hasn't even been notified via IPI seems wrong.
Yes. Does the below fix it up for you?
Sched: clear_tsk_need_resched() after pull_task() when NEWIDLE balancing
pull_task() may call set_tsk_need_resched() on a deactivated task,
leaving it vulnerable to an inappropriate preemption after wakeup.
This also confuses the skip_clock_update logic, which assumes that
schedule() will be called in very short order after being set. Make
that logic more robust by clearing in update_rq_clock() itself, so
only one update can be skipped.
Signed-off-by: Mike Galbraith <efault@gmx.de>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Bjoern B. Brandenburg <bbb.lst@gmail.com>
Reported-by: Bjoern B. Brandenburg <bbb.lst@gmail.com>
---
kernel/sched.c | 3 ++-
kernel/sched_fair.c | 10 ++++++++--
2 files changed, 10 insertions(+), 3 deletions(-)
Index: linux-2.6/kernel/sched.c
===================================================================
--- linux-2.6.orig/kernel/sched.c
+++ linux-2.6/kernel/sched.c
@@ -657,6 +657,8 @@ inline void update_rq_clock(struct rq *r
sched_irq_time_avg_update(rq, irq_time);
}
+
+ rq->skip_clock_update = 0;
}
/*
@@ -3714,7 +3716,6 @@ static void put_prev_task(struct rq *rq,
{
if (prev->se.on_rq)
update_rq_clock(rq);
- rq->skip_clock_update = 0;
prev->sched_class->put_prev_task(rq, prev);
}
Index: linux-2.6/kernel/sched_fair.c
===================================================================
--- linux-2.6.orig/kernel/sched_fair.c
+++ linux-2.6/kernel/sched_fair.c
@@ -2019,15 +2019,21 @@ balance_tasks(struct rq *this_rq, int th
pulled++;
rem_load_move -= p->se.load.weight;
-#ifdef CONFIG_PREEMPT
/*
+ * pull_task() may have set_tsk_need_resched(). Clear it
+ * lest a sleeper awaken and be inappropriately preempted
+ * shortly thereafter.
+ *
* NEWIDLE balancing is a source of latency, so preemptible
* kernels will stop after the first task is pulled to minimize
* the critical section.
*/
- if (idle == CPU_NEWLY_IDLE)
+ if (idle == CPU_NEWLY_IDLE) {
+ clear_tsk_need_resched(this_rq->curr);
+#ifdef CONFIG_PREEMPT
break;
#endif
+ }
/*
* We only want to steal up to the prescribed amount of
next prev parent reply other threads:[~2010-11-21 17:14 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-21 4:22 Bjoern B. Brandenburg
2010-11-21 17:14 ` Mike Galbraith [this message]
2010-11-22 4:29 ` Bjoern B. Brandenburg
2010-11-22 16:19 ` Mike Galbraith
2010-11-22 18:14 ` Bjoern B. Brandenburg
2010-12-04 7:42 ` Yong Zhang
2010-12-04 14:05 ` Yong Zhang
2010-12-04 14:08 ` Yong Zhang
2010-12-04 14:33 ` Yong Zhang
2010-12-05 5:28 ` Yong Zhang
2010-12-06 5:33 ` Mike Galbraith
2010-12-06 7:59 ` Yong Zhang
2010-12-06 8:32 ` [patchlet] " Mike Galbraith
2010-12-07 16:41 ` Peter Zijlstra
2010-12-07 18:55 ` Mike Galbraith
2010-12-08 10:05 ` Mike Galbraith
2010-12-08 11:12 ` Peter Zijlstra
2010-12-08 20:40 ` [tip:sched/urgent] Sched: fix skip_clock_update optimization tip-bot for Mike Galbraith
2010-12-09 15:32 ` Peter Zijlstra
2010-12-10 2:33 ` Yong Zhang
2010-12-10 16:17 ` Peter Zijlstra
2010-12-06 15:40 ` Scheduler bug related to rq->skip_clock_update? Bjoern B. Brandenburg
2010-12-03 12:41 ` Peter Zijlstra
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1290359641.4816.69.camel@maggy.simson.net \
--to=efault@gmx.de \
--cc=anderson@cs.unc.edu \
--cc=bastoni@sprg.uniroma2.it \
--cc=bbb.lst@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome