From: Chris Redpath <chris.redpath@arm.com>
To: pjt@google.com, mingo@redhat.com, peterz@infradead.org,
alex.shi@linaro.org, morten.rasmussen@arm.com,
dietmar.eggemann@arm.com
Cc: linux-kernel@vger.kernel.org, Chris Redpath <chris.redpath@arm.com>
Subject: [PATCH 2/2] sched: update runqueue clock before migrations away
Date: Mon, 9 Dec 2013 12:59:10 +0000 [thread overview]
Message-ID: <1386593950-26475-3-git-send-email-chris.redpath@arm.com> (raw)
In-Reply-To: <1386593950-26475-1-git-send-email-chris.redpath@arm.com>
If we migrate a sleeping task away from a CPU which has the
tick stopped, then both the clock_task and decay_counter will
be out of date for that CPU and we will not decay load correctly
regardless of how often we update the blocked load.
This is only an issue for tasks which are not on a runqueue
(because otherwise that CPU would be awake) and simultaneously
the CPU the task previously ran on has had the tick stopped.
Signed-off-by: Chris Redpath <chris.redpath@arm.com>
---
kernel/sched/fair.c | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index b7e5945..0af1dc2 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -4324,6 +4324,7 @@ unlock:
return new_cpu;
}
+static int nohz_test_cpu(int cpu);
/*
* Called immediately before a task is migrated to a new cpu; task_cpu(p) and
* cfs_rq_of(p) references at time of call are still valid and identify the
@@ -4343,6 +4344,25 @@ migrate_task_rq_fair(struct task_struct *p, int next_cpu)
* be negative here since on-rq tasks have decay-count == 0.
*/
if (se->avg.decay_count) {
+ /*
+ * If we migrate a sleeping task away from a CPU
+ * which has the tick stopped, then both the clock_task
+ * and decay_counter will be out of date for that CPU
+ * and we will not decay load correctly.
+ */
+ if (!se->on_rq && nohz_test_cpu(task_cpu(p))) {
+ struct rq *rq = cpu_rq(task_cpu(p));
+ unsigned long flags;
+ /*
+ * Current CPU cannot be holding rq->lock in this
+ * circumstance, but another might be. We must hold
+ * rq->lock before we go poking around in its clocks
+ */
+ raw_spin_lock_irqsave(&rq->lock, flags);
+ update_rq_clock(rq);
+ update_cfs_rq_blocked_load(cfs_rq, 0);
+ raw_spin_unlock_irqrestore(&rq->lock, flags);
+ }
se->avg.decay_count = -__synchronize_entity_decay(se);
atomic_long_add(se->avg.load_avg_contrib,
&cfs_rq->removed_load);
@@ -6507,6 +6527,11 @@ static struct {
unsigned long next_balance; /* in jiffy units */
} nohz ____cacheline_aligned;
+static int nohz_test_cpu(int cpu)
+{
+ return cpumask_test_cpu(cpu, nohz.idle_cpus_mask);
+}
+
static inline int find_new_ilb(int call_cpu)
{
int ilb = cpumask_first(nohz.idle_cpus_mask);
@@ -6619,6 +6644,11 @@ static int sched_ilb_notifier(struct notifier_block *nfb,
return NOTIFY_DONE;
}
}
+#else
+static int nohz_test_cpu(int cpu)
+{
+ return 0;
+}
#endif
static DEFINE_SPINLOCK(balancing);
--
1.7.9.5
next prev parent reply other threads:[~2013-12-09 12:59 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-09 12:59 [PATCH 0/2] Per-task load tracking errors Chris Redpath
2013-12-09 12:59 ` [PATCH 1/2] sched: reset blocked load decay_count during synchronization Chris Redpath
2013-12-09 17:59 ` bsegall
2013-12-09 12:59 ` Chris Redpath [this message]
2013-12-09 18:13 ` [PATCH 2/2] sched: update runqueue clock before migrations away bsegall
2013-12-10 11:48 ` Peter Zijlstra
2013-12-10 13:24 ` Chris Redpath
2013-12-10 15:14 ` Peter Zijlstra
2013-12-10 15:55 ` Chris Redpath
2013-12-12 18:24 ` Peter Zijlstra
2013-12-13 8:48 ` Vincent Guittot
2013-12-17 14:09 ` Chris Redpath
2013-12-17 15:51 ` Peter Zijlstra
2013-12-17 18:03 ` bsegall
2013-12-18 10:13 ` Chris Redpath
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=1386593950-26475-3-git-send-email-chris.redpath@arm.com \
--to=chris.redpath@arm.com \
--cc=alex.shi@linaro.org \
--cc=dietmar.eggemann@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=morten.rasmussen@arm.com \
--cc=peterz@infradead.org \
--cc=pjt@google.com \
/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