All of lore.kernel.org
 help / color / mirror / Atom feed
From: Valentin Schneider <valentin.schneider@arm.com>
To: linux-kernel@vger.kernel.org
Cc: peterz@infradead.org, mingo@kernel.org,
	vincent.guittot@linaro.org, dietmar.eggemann@arm.com,
	patrick.bellasi@matbug.net, qperret@google.com,
	qais.yousef@arm.com, morten.rasmussen@arm.com
Subject: [PATCH v2 4/4] sched/fair: Make feec() consider uclamp restrictions
Date: Tue,  3 Dec 2019 15:59:07 +0000	[thread overview]
Message-ID: <20191203155907.2086-5-valentin.schneider@arm.com> (raw)
In-Reply-To: <20191203155907.2086-1-valentin.schneider@arm.com>

We've just made task_fits_capacity() uclamp-aware, and
find_energy_efficient_cpu() needs to go through the same treatment.
Things are somewhat different here however - we can't directly use
the now uclamp-aware task_fits_capacity(). Consider the following setup:

  rq.cpu_capacity_orig = 512
  rq.util_avg = 200
  rq.uclamp.max = 768

  p.util_est = 600
  p.uclamp.max = 256

  (p not yet enqueued on rq)

Using task_fits_capacity() here would tell us that p fits on the above CPU.
However, enqueuing p on that CPU *will* cause it to become overutilized
since rq clamp values are max-aggregated, so we'd remain with

  rq.uclamp.max = 768

Thus we could reach a high enough frequency to reach beyond 0.8 * 512
utilization (== overutilized). What feec() needs here is
uclamp_rq_util_with() which lets us peek at the future utilization
landscape, including rq-wide uclamp values.

Make find_energy_efficient_cpu() use uclamp_rq_util_with() for its
fits_capacity() check. This is in line with what compute_energy() ends up
using for estimating utilization.

Suggested-by: Quentin Perret <qperret@google.com>
Signed-off-by: Valentin Schneider <valentin.schneider@arm.com>
---
 kernel/sched/fair.c | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index dc3e86cb2b2e..cc659a3944f1 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -6284,9 +6284,18 @@ static int find_energy_efficient_cpu(struct task_struct *p, int prev_cpu)
 			if (!cpumask_test_cpu(cpu, p->cpus_ptr))
 				continue;
 
-			/* Skip CPUs that will be overutilized. */
 			util = cpu_util_next(cpu, p, cpu);
 			cpu_cap = capacity_of(cpu);
+			spare_cap = cpu_cap - util;
+
+			/*
+			 * Skip CPUs that cannot satisfy the capacity request.
+			 * IOW, placing the task there would make the CPU
+			 * overutilized. Take uclamp into account to see how
+			 * much capacity we can get out of the CPU; this is
+			 * aligned with schedutil_cpu_util().
+			 */
+			util = uclamp_rq_util_with(cpu_rq(cpu), util, p);
 			if (!fits_capacity(util, cpu_cap))
 				continue;
 
@@ -6301,7 +6310,6 @@ static int find_energy_efficient_cpu(struct task_struct *p, int prev_cpu)
 			 * Find the CPU with the maximum spare capacity in
 			 * the performance domain
 			 */
-			spare_cap = cpu_cap - util;
 			if (spare_cap > max_spare_cap) {
 				max_spare_cap = spare_cap;
 				max_spare_cap_cpu = cpu;
-- 
2.24.0


  parent reply	other threads:[~2019-12-03 16:02 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-03 15:59 [PATCH v2 0/4] sched/fair: Task placement biasing using uclamp Valentin Schneider
2019-12-03 15:59 ` [PATCH v2 1/4] sched/uclamp: Make uclamp_util_*() helpers use and return UL values Valentin Schneider
2019-12-04 15:22   ` Vincent Guittot
2019-12-04 16:03     ` Valentin Schneider
2019-12-04 16:12       ` Vincent Guittot
2019-12-04 16:25         ` Rainer Sickinger
2019-12-04 17:15         ` Valentin Schneider
2019-12-04 17:29           ` Vincent Guittot
2019-12-04 17:35             ` Valentin Schneider
2019-12-10 18:09   ` Dietmar Eggemann
2019-12-10 18:31     ` Valentin Schneider
2019-12-03 15:59 ` [PATCH v2 2/4] sched/uclamp: Rename uclamp_util_*() into uclamp_rq_util_*() Valentin Schneider
2019-12-03 15:59 ` [PATCH v2 3/4] sched/fair: Make task_fits_capacity() consider uclamp restrictions Valentin Schneider
2019-12-10 17:07   ` Dietmar Eggemann
2019-12-10 17:10     ` Valentin Schneider
2019-12-03 15:59 ` Valentin Schneider [this message]
2019-12-10 18:23   ` [PATCH v2 4/4] sched/fair: Make feec() " Dietmar Eggemann
2019-12-10 18:35     ` Valentin Schneider

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=20191203155907.2086-5-valentin.schneider@arm.com \
    --to=valentin.schneider@arm.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=morten.rasmussen@arm.com \
    --cc=patrick.bellasi@matbug.net \
    --cc=peterz@infradead.org \
    --cc=qais.yousef@arm.com \
    --cc=qperret@google.com \
    --cc=vincent.guittot@linaro.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.