From: Peter Zijlstra <peterz@infradead.org>
To: mingo@kernel.org, lvenanci@redhat.com
Cc: lwang@redhat.com, riel@redhat.com, efault@gmx.de,
tglx@linutronix.de, linux-kernel@vger.kernel.org,
peterz@infradead.org
Subject: [PATCH 13/14] sched/topology: Fix overlapping sched_group_capacity
Date: Fri, 28 Apr 2017 15:20:11 +0200 [thread overview]
Message-ID: <20170428132503.010046077@infradead.org> (raw)
In-Reply-To: <20170428131958.893188882@infradead.org>
[-- Attachment #1: peterz-sched-topo-sched-group-capacity.patch --]
[-- Type: text/plain, Size: 5235 bytes --]
When building the overlapping groups we need to attach a consistent
sched_group_capacity structure. That is, all 'identical' sched_group's
should have the _same_ sched_group_capacity.
This can (once again) be demonstrated with a topology like:
node 0 1 2 3
0: 10 20 30 20
1: 20 10 20 30
2: 30 20 10 20
3: 20 30 20 10
But we need at least 2 CPUs per node for this to show up, after all,
if there is only one CPU per node, our CPU @i is per definition a
unique CPU that reaches this domain (aka balance-cpu).
Given the above NUMA topo and 2 CPUs per node:
[] CPU0 attaching sched-domain(s):
[] domain-0: span=0,4 level=DIE
[] groups: 0:{ span=0 }, 4:{ span=4 }
[] domain-1: span=0-1,3-5,7 level=NUMA
[] groups: 0:{ span=0,4 mask=0,4 cap=2048 }, 1:{ span=1,5 mask=1,5 cap=2048 }, 3:{ span=3,7 mask=3,7 cap=2048 }
[] domain-2: span=0-7 level=NUMA
[] groups: 0:{ span=0-1,3-5,7 mask=0,4 cap=6144 }, 2:{ span=1-3,5-7 mask=2,6 cap=6144 }
[] CPU1 attaching sched-domain(s):
[] domain-0: span=1,5 level=DIE
[] groups: 1:{ span=1 }, 5:{ span=5 }
[] domain-1: span=0-2,4-6 level=NUMA
[] groups: 1:{ span=1,5 mask=1,5 cap=2048 }, 2:{ span=2,6 mask=2,6 cap=2048 }, 4:{ span=0,4 mask=0,4 cap=2048 }
[] domain-2: span=0-7 level=NUMA
[] groups: 1:{ span=0-2,4-6 mask=1,5 cap=6144 }, 3:{ span=0,2-4,6-7 mask=3,7 cap=6144 }
Observe how CPU0-domain1-group0 and CPU1-domain1-group4 are the
'same' but have a different id (0 vs 4).
To fix this, use the group balance CPU to select the SGC. This means
we have to compute the full mask for each CPU and require a second
temporary mask to store the group mask in (it otherwise lives in the
SGC).
The fixed topology looks like:
[] CPU0 attaching sched-domain(s):
[] domain-0: span=0,4 level=DIE
[] groups: 0:{ span=0 }, 4:{ span=4 }
[] domain-1: span=0-1,3-5,7 level=NUMA
[] groups: 0:{ span=0,4 mask=0,4 cap=2048 }, 1:{ span=1,5 mask=1,5 cap=2048 }, 3:{ span=3,7 mask=3,7 cap=2048 }
[] domain-2: span=0-7 level=NUMA
[] groups: 0:{ span=0-1,3-5,7 mask=0,4 cap=6144 }, 2:{ span=1-3,5-7 mask=2,6 cap=6144 }
[] CPU1 attaching sched-domain(s):
[] domain-0: span=1,5 level=DIE
[] groups: 1:{ span=1 }, 5:{ span=5 }
[] domain-1: span=0-2,4-6 level=NUMA
[] groups: 1:{ span=1,5 mask=1,5 cap=2048 }, 2:{ span=2,6 mask=2,6 cap=2048 }, 0:{ span=0,4 mask=0,4 cap=2048 }
[] domain-2: span=0-7 level=NUMA
[] groups: 1:{ span=0-2,4-6 mask=1,5 cap=6144 }, 3:{ span=0,2-4,6-7 mask=3,7 cap=6144 }
Fixes: e3589f6c81e4 ("sched: Allow for overlapping sched_domain spans")
Debugged-by: Lauro Ramos Venancio <lvenanci@redhat.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
---
kernel/sched/topology.c | 22 ++++++++++++++++------
1 file changed, 16 insertions(+), 6 deletions(-)
--- a/kernel/sched/topology.c
+++ b/kernel/sched/topology.c
@@ -10,6 +10,7 @@ DEFINE_MUTEX(sched_domains_mutex);
/* Protected by sched_domains_mutex: */
cpumask_var_t sched_domains_tmpmask;
+cpumask_var_t sched_domains_tmpmask2;
#ifdef CONFIG_SCHED_DEBUG
@@ -500,13 +501,16 @@ enum s_alloc {
* Only CPUs that can arrive at this group should be considered to continue
* balancing.
*/
-static void build_group_mask(struct sched_domain *sd, struct sched_group *sg)
+static void
+build_group_mask(struct sched_domain *sd, struct sched_group *sg, struct cpumask *mask)
{
const struct cpumask *sg_span = sched_group_cpus(sg);
struct sd_data *sdd = sd->private;
struct sched_domain *sibling;
int i;
+ cpumask_clear(mask);
+
for_each_cpu(i, sg_span) {
sibling = *per_cpu_ptr(sdd->sd, i);
@@ -522,11 +526,11 @@ static void build_group_mask(struct sche
if (!cpumask_equal(sg_span, sched_domain_span(sibling->child)))
continue;
- cpumask_set_cpu(i, sched_group_mask(sg));
+ cpumask_set_cpu(i, mask);
}
/* We must not have empty masks here */
- WARN_ON_ONCE(cpumask_empty(sched_group_mask(sg)));
+ WARN_ON_ONCE(cpumask_empty(mask));
}
/*
@@ -560,14 +564,19 @@ build_group_from_child_sched_domain(stru
}
static void init_overlap_sched_group(struct sched_domain *sd,
- struct sched_group *sg, int cpu)
+ struct sched_group *sg)
{
+ struct cpumask *mask = sched_domains_tmpmask2;
struct sd_data *sdd = sd->private;
struct cpumask *sg_span;
+ int cpu;
+
+ build_group_mask(sd, sg, mask);
+ cpu = cpumask_first_and(sched_group_cpus(sg), mask);
sg->sgc = *per_cpu_ptr(sdd->sgc, cpu);
if (atomic_inc_return(&sg->sgc->ref) == 1)
- build_group_mask(sd, sg);
+ cpumask_copy(sched_group_mask(sg), mask);
/*
* Initialize sgc->capacity such that even if we mess up the
@@ -619,7 +628,7 @@ build_overlap_sched_groups(struct sched_
sg_span = sched_group_cpus(sg);
cpumask_or(covered, covered, sg_span);
- init_overlap_sched_group(sd, sg, i);
+ init_overlap_sched_group(sd, sg);
if (!first)
first = sg;
@@ -1578,6 +1587,7 @@ int sched_init_domains(const struct cpum
int err;
zalloc_cpumask_var(&sched_domains_tmpmask, GFP_KERNEL);
+ zalloc_cpumask_var(&sched_domains_tmpmask2, GFP_KERNEL);
zalloc_cpumask_var(&fallback_doms, GFP_KERNEL);
arch_update_cpu_topology();
next prev parent reply other threads:[~2017-04-28 13:33 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-28 13:19 [PATCH 00/14] sched/topology fixes Peter Zijlstra
2017-04-28 13:19 ` [PATCH 01/14] sched/topology: Refactor function build_overlap_sched_groups() Peter Zijlstra
2017-04-28 13:20 ` [PATCH 02/14] sched,cpumask: Export for_each_cpu_wrap() Peter Zijlstra
2017-05-01 19:56 ` Rik van Riel
2017-04-28 13:20 ` [PATCH 03/14] sched/topology: Fix building of overlapping sched-groups Peter Zijlstra
2017-05-01 20:08 ` Rik van Riel
2017-04-28 13:20 ` [PATCH 04/14] sched/topology: Simplify build_overlap_sched_groups() Peter Zijlstra
2017-05-01 21:04 ` Rik van Riel
2017-04-28 13:20 ` [PATCH 05/14] sched/topology,debug: Print the group mask Peter Zijlstra
2017-05-01 21:13 ` Rik van Riel
2017-04-28 13:20 ` [PATCH 06/14] sched/topology,debug: Verify the first group matches the child domain Peter Zijlstra
2017-05-01 21:13 ` Rik van Riel
2017-05-02 14:52 ` Peter Zijlstra
2017-05-03 15:00 ` Rik van Riel
2017-04-28 13:20 ` [PATCH 07/14] sched/topology: Optimize build_group_mask() Peter Zijlstra
2017-05-02 0:57 ` Rik van Riel
2017-04-28 13:20 ` [PATCH 08/14] sched/topology: Move comment about asymmetric node setups Peter Zijlstra
2017-05-02 1:08 ` Rik van Riel
2017-04-28 13:20 ` [PATCH 09/14] sched/topology: Remove FORCE_SD_OVERLAP Peter Zijlstra
2017-05-02 1:09 ` Rik van Riel
2017-04-28 13:20 ` [PATCH 10/14] sched/topology: Fix overlapping sched_group_mask Peter Zijlstra
2017-04-28 13:20 ` [PATCH 11/14] sched/topology: Small cleanup Peter Zijlstra
2017-04-28 13:20 ` [PATCH 12/14] sched/topology,debug: Add sched_group_capacity debugging Peter Zijlstra
2017-04-28 13:20 ` Peter Zijlstra [this message]
2017-04-28 13:20 ` [PATCH 14/14] sched/topology: Add a few comments Peter Zijlstra
2017-05-01 8:35 ` Peter Zijlstra
2017-04-28 13:53 ` [PATCH 00/14] sched/topology fixes Peter Zijlstra
2017-04-28 23:30 ` Lauro Venancio
2017-05-01 8:57 ` Peter Zijlstra
2017-05-02 14:43 ` Peter Zijlstra
2017-05-02 14:54 ` Lauro Venancio
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=20170428132503.010046077@infradead.org \
--to=peterz@infradead.org \
--cc=efault@gmx.de \
--cc=linux-kernel@vger.kernel.org \
--cc=lvenanci@redhat.com \
--cc=lwang@redhat.com \
--cc=mingo@kernel.org \
--cc=riel@redhat.com \
--cc=tglx@linutronix.de \
/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®