linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "tip-bot2 for Ionela Voinescu" <tip-bot2@linutronix.de>
To: linux-tip-commits@vger.kernel.org
Cc: Quentin Perret <qperret@google.com>,
	Ionela Voinescu <ionela.voinescu@arm.com>,
	"Peter Zijlstra (Intel)" <peterz@infradead.org>,
	x86@kernel.org, linux-kernel@vger.kernel.org
Subject: [tip: sched/core] sched/topology: Condition EAS enablement on FIE support
Date: Fri, 20 Nov 2020 12:34:04 -0000	[thread overview]
Message-ID: <160587564437.11244.7301839109814236795.tip-bot2@tip-bot2> (raw)
In-Reply-To: <20201027180713.7642-4-ionela.voinescu@arm.com>

The following commit has been merged into the sched/core branch of tip:

Commit-ID:     fa50e2b452c60cff9f4000de5b372a61d6695c26
Gitweb:        https://git.kernel.org/tip/fa50e2b452c60cff9f4000de5b372a61d6695c26
Author:        Ionela Voinescu <ionela.voinescu@arm.com>
AuthorDate:    Tue, 27 Oct 2020 18:07:13 
Committer:     Peter Zijlstra <peterz@infradead.org>
CommitterDate: Thu, 19 Nov 2020 11:25:47 +01:00

sched/topology: Condition EAS enablement on FIE support

In order to make accurate predictions across CPUs and for all performance
states, Energy Aware Scheduling (EAS) needs frequency-invariant load
tracking signals.

EAS task placement aims to minimize energy consumption, and does so in
part by limiting the search space to only CPUs with the highest spare
capacity (CPU capacity - CPU utilization) in their performance domain.
Those candidates are the placement choices that will keep frequency at
its lowest possible and therefore save the most energy.

But without frequency invariance, a CPU's utilization is relative to the
CPU's current performance level, and not relative to its maximum
performance level, which determines its capacity. As a result, it will
fail to correctly indicate any potential spare capacity obtained by an
increase in a CPU's performance level. Therefore, a non-invariant
utilization signal would render the EAS task placement logic invalid.

Now that we properly report support for the Frequency Invariance Engine
(FIE) through arch_scale_freq_invariant() for arm and arm64 systems,
while also ensuring a re-evaluation of the EAS use conditions for
possible invariance status change, we can assert this is the case when
initializing EAS. Warn and bail out otherwise.

Suggested-by: Quentin Perret <qperret@google.com>
Signed-off-by: Ionela Voinescu <ionela.voinescu@arm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/20201027180713.7642-4-ionela.voinescu@arm.com
---
 kernel/sched/topology.c |  9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c
index 04d9ebf..5d3675c 100644
--- a/kernel/sched/topology.c
+++ b/kernel/sched/topology.c
@@ -328,6 +328,7 @@ static void sched_energy_set(bool has_eas)
  *    3. no SMT is detected.
  *    4. the EM complexity is low enough to keep scheduling overheads low;
  *    5. schedutil is driving the frequency of all CPUs of the rd;
+ *    6. frequency invariance support is present;
  *
  * The complexity of the Energy Model is defined as:
  *
@@ -376,6 +377,14 @@ static bool build_perf_domains(const struct cpumask *cpu_map)
 		goto free;
 	}
 
+	if (!arch_scale_freq_invariant()) {
+		if (sched_debug()) {
+			pr_warn("rd %*pbl: Disabling EAS: frequency-invariant load tracking not yet supported",
+				cpumask_pr_args(cpu_map));
+		}
+		goto free;
+	}
+
 	for_each_cpu(i, cpu_map) {
 		/* Skip already covered CPUs. */
 		if (find_pd(pd, i))

  reply	other threads:[~2020-11-20 12:34 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-27 18:07 [PATCH RESEND v2 0/3] condition EAS enablement on FI support Ionela Voinescu
2020-10-27 18:07 ` [PATCH RESEND v2 1/3] sched/topology,schedutil: wrap sched domains rebuild Ionela Voinescu
2020-10-30 15:26   ` Rafael J. Wysocki
2020-11-05 14:03     ` Ionela Voinescu
2020-11-20 12:34   ` [tip: sched/core] sched/topology,schedutil: Wrap " tip-bot2 for Ionela Voinescu
2020-10-27 18:07 ` [PATCH RESEND v2 2/3] arm64: rebuild sched domains on invariance status changes Ionela Voinescu
2020-11-10 17:20   ` Catalin Marinas
2020-11-20 12:34   ` [tip: sched/core] arm64: Rebuild " tip-bot2 for Ionela Voinescu
2020-10-27 18:07 ` [PATCH RESEND v2 3/3] sched/topology: condition EAS enablement on FIE support Ionela Voinescu
2020-11-20 12:34   ` tip-bot2 for Ionela Voinescu [this message]
2020-11-18 11:42 ` [PATCH RESEND v2 0/3] condition EAS enablement on FI support Ionela Voinescu
2020-11-18 14:01   ` 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=160587564437.11244.7301839109814236795.tip-bot2@tip-bot2 \
    --to=tip-bot2@linutronix.de \
    --cc=ionela.voinescu@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tip-commits@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=qperret@google.com \
    --cc=x86@kernel.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;
as well as URLs for NNTP newsgroup(s).