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 v3 5/5] sched/fair: Make EAS wakeup placement consider uclamp restrictions
Date: Wed, 11 Dec 2019 11:38:51 +0000	[thread overview]
Message-ID: <20191211113851.24241-6-valentin.schneider@arm.com> (raw)
In-Reply-To: <20191211113851.24241-1-valentin.schneider@arm.com>

task_fits_capacity() has just been made uclamp-aware, and
find_energy_efficient_cpu() needs to go through the same treatment.

Things are somewhat different here however - using the task max clamp isn't
sufficient. Consider the following setup:

  The target runqueue, rq:
    rq.cpu_capacity_orig = 512
    rq.cfs.avg.util_avg = 200
    rq.uclamp.max = 768 // the max p.uclamp.max of all enqueued p's is 768

  The waking task, p (not yet enqueued on rq):
    p.util_est = 600
    p.uclamp.max = 100

Now, consider the following code which doesn't use the rq clamps:

  util = uclamp_task_util(p);
  // Does the task fit in the spare CPU capacity?
  cpu = cpu_of(rq);
  fits_capacity(util, cpu_capacity(cpu) - cpu_util(cpu))

This would lead to:

  util = 100;
  fits_capacity(100, 512 - 200)

fits_capacity() would return true. 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

which comes from the other tasks already enqueued on rq. Thus, we could
select a high enough frequency to reach beyond 0.8 * 512 utilization
(== overutilized) after enqueuing p on rq. What find_energy_efficient_cpu()
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>
Reviewed-by: Vincent Guittot <vincent.guittot@linaro.org>
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 a9c93c5427bf..956d9578935a 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -6282,9 +6282,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;
 
@@ -6299,7 +6308,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-11 11:39 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-11 11:38 [PATCH v3 0/5] sched/fair: Task placement biasing using uclamp Valentin Schneider
2019-12-11 11:38 ` [PATCH v3 1/5] sched/uclamp: Remove uclamp_util() Valentin Schneider
2019-12-25 10:39   ` [tip: sched/core] " tip-bot2 for Valentin Schneider
2019-12-11 11:38 ` [PATCH v3 2/5] sched/uclamp: Make uclamp util helpers use and return UL values Valentin Schneider
2019-12-25 10:39   ` [tip: sched/core] " tip-bot2 for Valentin Schneider
2019-12-11 11:38 ` [PATCH v3 3/5] sched/uclamp: Rename uclamp_util_with() into uclamp_rq_util_with() Valentin Schneider
2019-12-25 10:39   ` [tip: sched/core] " tip-bot2 for Valentin Schneider
2019-12-11 11:38 ` [PATCH v3 4/5] sched/fair: Make task_fits_capacity() consider uclamp restrictions Valentin Schneider
2019-12-25 10:39   ` [tip: sched/core] " tip-bot2 for Valentin Schneider
2019-12-11 11:38 ` Valentin Schneider [this message]
2019-12-25 10:38   ` [tip: sched/core] sched/fair: Make EAS wakeup placement " tip-bot2 for Valentin Schneider
2019-12-12 15:06 ` [PATCH v3 0/5] sched/fair: Task placement biasing using uclamp Dietmar Eggemann
2019-12-20 15:04   ` 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=20191211113851.24241-6-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.