From: Chris Redpath <chris.redpath@arm.com>
To: linux-kernel@vger.kernel.org
Cc: Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
morten.rasmussen@arm.com, dietmar.eggemann@arm.com,
Chris Redpath <chris.redpath@arm.com>
Subject: [PATCH] sched/fair: Update rq_clock, cfs_rq before migrating for asym cpu capacity
Date: Tue, 9 Jul 2019 12:57:59 +0100 [thread overview]
Message-ID: <20190709115759.10451-1-chris.redpath@arm.com> (raw)
The ancient workaround to avoid the cost of updating rq clocks in the
middle of a migration causes some issues on asymmetric CPU capacity
systems where we use task utilization to determine which cpus fit a task.
On quiet systems we can inflate task util after a migration which
causes misfit to fire and force-migrate the task.
This occurs when:
(a) a task has util close to the non-overutilized capacity limit of a
particular cpu (cpu0 here); and
(b) the prev_cpu was quiet otherwise, such that rq clock is
sufficiently out of date (cpu1 here).
e.g.
_____
cpu0: ________________________| |______________
|<- misfit happens
______ ___ ___
cpu1: ____| |______________|___| |_________|
->| |<- wakeup migration time
last rq clock update
When the task util is in just the right range for the system, we can end
up migrating an unlucky task back and forth many times until we are lucky
and the source rq happens to be updated close to the migration time.
In order to address this, lets update both rq_clock and cfs_rq where
this could be an issue.
Signed-off-by: Chris Redpath <chris.redpath@arm.com>
---
kernel/sched/fair.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index b798fe7ff7cd..51791db26a2a 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -6545,6 +6545,21 @@ static void migrate_task_rq_fair(struct task_struct *p, int new_cpu)
* wakee task is less decayed, but giving the wakee more load
* sounds not bad.
*/
+ if (static_branch_unlikely(&sched_asym_cpucapacity) &&
+ p->state == TASK_WAKING) {
+ /*
+ * On asymmetric capacity systems task util guides
+ * wake placement so update rq_clock and cfs_rq
+ */
+ struct cfs_rq *cfs_rq = task_cfs_rq(p);
+ struct rq *rq = task_rq(p);
+ struct rq_flags rf;
+
+ rq_lock_irqsave(rq, &rf);
+ update_rq_clock(rq);
+ update_cfs_rq_load_avg(cfs_rq_clock_pelt(cfs_rq), cfs_rq);
+ rq_unlock_irqrestore(rq, &rf);
+ }
remove_entity_load_avg(&p->se);
}
--
2.17.1
next reply other threads:[~2019-07-09 11:58 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-09 11:57 Chris Redpath [this message]
2019-07-09 13:50 ` [PATCH] sched/fair: Update rq_clock, cfs_rq before migrating for asym cpu capacity Peter Zijlstra
2019-07-09 15:23 ` Chris Redpath
2019-07-09 15:36 ` Vincent Guittot
2019-07-09 15:42 ` Chris Redpath
2019-07-09 15:46 ` Vincent Guittot
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=20190709115759.10451-1-chris.redpath@arm.com \
--to=chris.redpath@arm.com \
--cc=dietmar.eggemann@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=morten.rasmussen@arm.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.