mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "tip-bot2 for Valentin Schneider" <tip-bot2@linutronix.de>
To: linux-tip-commits@vger.kernel.org
Cc: Valentin Schneider <valentin.schneider@arm.com>,
	Ingo Molnar <mingo@kernel.org>,
	Quentin Perret <qperret@google.com>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>, x86 <x86@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: [tip: sched/core] sched/topology: Propagate SD_ASYM_CPUCAPACITY upwards
Date: Wed, 19 Aug 2020 14:02:45 -0000	[thread overview]
Message-ID: <159784576564.3192.9478277470709214393.tip-bot2@tip-bot2> (raw)
In-Reply-To: <20200817113003.20802-11-valentin.schneider@arm.com>

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

Commit-ID:     c200191d4c2c1aa2ffb62a984b756ac1f02dc55c
Gitweb:        https://git.kernel.org/tip/c200191d4c2c1aa2ffb62a984b756ac1f02dc55c
Author:        Valentin Schneider <valentin.schneider@arm.com>
AuthorDate:    Mon, 17 Aug 2020 12:29:56 +01:00
Committer:     Ingo Molnar <mingo@kernel.org>
CommitterDate: Wed, 19 Aug 2020 10:49:49 +02:00

sched/topology: Propagate SD_ASYM_CPUCAPACITY upwards

We currently set this flag *only* on domains whose topology level exactly
match the level where we detect asymmetry (as returned by
asym_cpu_capacity_level()). This is rather problematic.

Say there are two clusters in the system, one with a lone big CPU and the
other with a mix of big and LITTLE CPUs (as is allowed by DynamIQ):

  DIE [                ]
  MC  [             ][ ]
       0   1   2   3  4
       L   L   B   B  B

asym_cpu_capacity_level() will figure out that the MC level is the one
where all CPUs can see a CPU of max capacity, and we will thus set
SD_ASYM_CPUCAPACITY at MC level for all CPUs.

That lone big CPU will degenerate its MC domain, since it would be alone in
there, and will end up with just a DIE domain. Since the flag was only set
at MC, this CPU ends up not seeing any SD with the flag set, which is
broken.

Rather than clearing dflags at every topology level, clear it before
entering the topology level loop. This will properly propagate upwards
flags that are set starting from a certain level.

Signed-off-by: Valentin Schneider <valentin.schneider@arm.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Reviewed-by: Quentin Perret <qperret@google.com>
Reviewed-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: https://lore.kernel.org/r/20200817113003.20802-11-valentin.schneider@arm.com
---
 include/linux/sched/sd_flags.h | 4 +++-
 kernel/sched/topology.c        | 3 +--
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/include/linux/sched/sd_flags.h b/include/linux/sched/sd_flags.h
index ee5cbfc..40ad0d5 100644
--- a/include/linux/sched/sd_flags.h
+++ b/include/linux/sched/sd_flags.h
@@ -83,9 +83,11 @@ SD_FLAG(SD_WAKE_AFFINE, SDF_SHARED_CHILD)
 /*
  * Domain members have different CPU capacities
  *
+ * SHARED_PARENT: Set from the topmost domain down to the first domain where
+ *                asymmetry is detected.
  * NEEDS_GROUPS: Per-CPU capacity is asymmetric between groups.
  */
-SD_FLAG(SD_ASYM_CPUCAPACITY, SDF_NEEDS_GROUPS)
+SD_FLAG(SD_ASYM_CPUCAPACITY, SDF_SHARED_PARENT | SDF_NEEDS_GROUPS)
 
 /*
  * Domain members share CPU capacity (i.e. SMT)
diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c
index c662c53..f36ed96 100644
--- a/kernel/sched/topology.c
+++ b/kernel/sched/topology.c
@@ -1988,11 +1988,10 @@ build_sched_domains(const struct cpumask *cpu_map, struct sched_domain_attr *att
 	/* Set up domains for CPUs specified by the cpu_map: */
 	for_each_cpu(i, cpu_map) {
 		struct sched_domain_topology_level *tl;
+		int dflags = 0;
 
 		sd = NULL;
 		for_each_sd_topology(tl) {
-			int dflags = 0;
-
 			if (tl == tl_asym) {
 				dflags |= SD_ASYM_CPUCAPACITY;
 				has_asym = true;

  reply	other threads:[~2020-08-19 14:04 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-17 11:29 [PATCH v6 00/17] sched: Instrument sched domain flags Valentin Schneider
2020-08-17 11:29 ` [PATCH v6 01/17] ARM, sched/topology: Remove SD_SHARE_POWERDOMAIN Valentin Schneider
2020-08-19 14:02   ` [tip: sched/core] " tip-bot2 for Valentin Schneider
2020-08-17 11:29 ` [PATCH v6 02/17] ARM: Revert back to default scheduler topology Valentin Schneider
2020-08-19 14:02   ` [tip: sched/core] ARM, sched/topology: " tip-bot2 for Valentin Schneider
2020-08-17 11:29 ` [PATCH v6 03/17] sched/topology: Split out SD_* flags declaration to its own file Valentin Schneider
2020-08-19 14:02   ` [tip: sched/core] " tip-bot2 for Valentin Schneider
2020-08-17 11:29 ` [PATCH v6 04/17] sched/topology: Define and assign sched_domain flag metadata Valentin Schneider
2020-08-19 14:02   ` [tip: sched/core] " tip-bot2 for Valentin Schneider
2020-08-17 11:29 ` [PATCH v6 05/17] sched/topology: Verify SD_* flags setup when sched_debug is on Valentin Schneider
2020-08-19 14:02   ` [tip: sched/core] " tip-bot2 for Valentin Schneider
2020-08-17 11:29 ` [PATCH v6 06/17] sched/debug: Output SD flag names rather than their values Valentin Schneider
2020-08-19 14:02   ` [tip: sched/core] " tip-bot2 for Valentin Schneider
2020-08-17 11:29 ` [PATCH v6 07/17] sched/topology: Introduce SD metaflag for flags needing > 1 groups Valentin Schneider
2020-08-19 14:02   ` [tip: sched/core] " tip-bot2 for Valentin Schneider
2020-08-17 11:29 ` [PATCH v6 08/17] sched/topology: Use prebuilt SD flag degeneration mask Valentin Schneider
2020-08-19 14:02   ` [tip: sched/core] " tip-bot2 for Valentin Schneider
2020-08-17 11:29 ` [PATCH v6 09/17] sched/topology: Remove SD_SERIALIZE degeneration special case Valentin Schneider
2020-08-19 14:02   ` [tip: sched/core] " tip-bot2 for Valentin Schneider
2020-08-17 11:29 ` [PATCH v6 10/17] sched/topology: Propagate SD_ASYM_CPUCAPACITY upwards Valentin Schneider
2020-08-19 14:02   ` tip-bot2 for Valentin Schneider [this message]
2020-08-17 11:29 ` [PATCH v6 11/17] sched/topology: Mark SD_PREFER_SIBLING as SDF_NEEDS_GROUPS Valentin Schneider
2020-08-19 14:02   ` [tip: sched/core] " tip-bot2 for Valentin Schneider
2020-08-17 11:29 ` [PATCH v6 12/17] sched/topology: Mark SD_BALANCE_WAKE " Valentin Schneider
2020-08-19 14:02   ` [tip: sched/core] " tip-bot2 for Valentin Schneider
2020-08-17 11:29 ` [PATCH v6 13/17] sched/topology: Mark SD_SERIALIZE " Valentin Schneider
2020-08-19 14:02   ` [tip: sched/core] " tip-bot2 for Valentin Schneider
2020-08-17 11:30 ` [PATCH v6 14/17] sched/topology: Mark SD_ASYM_PACKING " Valentin Schneider
2020-08-19 14:02   ` [tip: sched/core] " tip-bot2 for Valentin Schneider
2020-08-17 11:30 ` [PATCH v6 15/17] sched/topology: Mark SD_OVERLAP " Valentin Schneider
2020-08-19 14:02   ` [tip: sched/core] " tip-bot2 for Valentin Schneider
2020-08-17 11:30 ` [PATCH v6 16/17] sched/topology: Mark SD_NUMA " Valentin Schneider
2020-08-19 14:02   ` [tip: sched/core] " tip-bot2 for Valentin Schneider
2020-08-17 11:30 ` [PATCH v6 17/17] sched/topology: Expand use of SD_DEGENERATE_GROUPS_MASK to flags not needing groups 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=159784576564.3192.9478277470709214393.tip-bot2@tip-bot2 \
    --to=tip-bot2@linutronix.de \
    --cc=a.p.zijlstra@chello.nl \
    --cc=dietmar.eggemann@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tip-commits@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=qperret@google.com \
    --cc=valentin.schneider@arm.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

all inboxes | Powered by JetHome®