From: Dietmar Eggemann <dietmar.eggemann@arm.com>
To: Valentin Schneider <valentin.schneider@arm.com>,
linux-kernel@vger.kernel.org, cgroups@vger.kernel.org
Cc: lizefan@huawei.com, tj@kernel.org, hannes@cmpxchg.org,
mingo@kernel.org, peterz@infradead.org,
vincent.guittot@linaro.org, morten.rasmussen@arm.com,
qperret@google.com, stable@vger.kernel.org
Subject: Re: [PATCH v3 2/2] sched/topology: Allow sched_asym_cpucapacity to be disabled
Date: Wed, 23 Oct 2019 10:45:44 +0200 [thread overview]
Message-ID: <fb378e1c-4b13-5ac4-8c86-8422b5362c7b@arm.com> (raw)
In-Reply-To: <20191015154250.12951-3-valentin.schneider@arm.com>
On 15/10/2019 17:42, Valentin Schneider wrote:
> While the static key is correctly initialized as being disabled, it will
> remain forever enabled once turned on. This means that if we start with an
> asymmetric system and hotplug out enough CPUs to end up with an SMP system,
> the static key will remain set - which is obviously wrong. We should detect
> this and turn off things like misfit migration and capacity aware wakeups.
>
> As Quentin pointed out, having separate root domains makes this slightly
> trickier. We could have exclusive cpusets that create an SMP island - IOW,
> the domains within this root domain will not see any asymmetry. This means
> we need to count how many asymmetric root domains we have.
Could you make the example a little bit more obvious so we'll remember
later the exact testcase?
We start with 2 asym (hmp) (CPU capacity) exclusive cpusets and we turn
one into a sym (smp) exclusive cpuset via CPU hp.
This patch w/ extra debug on Juno [CPU0 - CPU5] = [L b b L L L]:
root@juno:~# ./scripts/create_excl_cpusets3
[ 32.898483] detach_destroy_domains(): sched_asym_cpucapacity is
disabled cpu_map=0-5
[ 32.906255] build_sched_domains(): sched_asym_cpucapacity is enabled
cpu_map=0-1,3
[ 32.913813] build_sched_domains(): sched_asym_cpucapacity is enabled
cpu_map=2,4-5
root@juno:~# echo 0 > /sys/devices/system/cpu/cpu1/online
[ 62.709591] IRQ 2: no longer affine to CPU1
[ 62.713840] CPU1: shutdown
[ 62.716525] psci: CPU1 killed.
root@juno:~# [ 62.728779] detach_destroy_domains():
sched_asym_cpucapacity still enabled cpu_map=0-1,3 <-- Your v1 would
just have disabled sched_asym_cpucapacity here.
A hint that systems with a mix of asym and sym CPU capacity rd's have to
live with the fact that specific asym code is also enabled for the CPUs
of the smp rd's wouldn't harm here.
Reviewed-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
> Change the simple key enablement to an increment, and decrement the key
> counter when destroying domains that cover asymmetric CPUs.
>
> Cc: <stable@vger.kernel.org>
> Fixes: df054e8445a4 ("sched/topology: Add static_key for asymmetric CPU capacity optimizations")
> Signed-off-by: Valentin Schneider <valentin.schneider@arm.com>
> ---
> kernel/sched/topology.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c
> index 9318acf1d1fe..f0e730143380 100644
> --- a/kernel/sched/topology.c
> +++ b/kernel/sched/topology.c
> @@ -2029,7 +2029,7 @@ build_sched_domains(const struct cpumask *cpu_map, struct sched_domain_attr *att
> rcu_read_unlock();
>
> if (has_asym)
> - static_branch_enable_cpuslocked(&sched_asym_cpucapacity);
> + static_branch_inc_cpuslocked(&sched_asym_cpucapacity);
>
> if (rq && sched_debug_enabled) {
> pr_info("root domain span: %*pbl (max cpu_capacity = %lu)\n",
> @@ -2125,7 +2125,10 @@ int sched_init_domains(const struct cpumask *cpu_map)
> static void detach_destroy_domains(const struct cpumask *cpu_map)
> {
> int i;
> + unsigned int cpu = cpumask_any(cpu_map);
> +
> + if (rcu_access_pointer(per_cpu(sd_asym_cpucapacity, cpu)))
> + static_branch_dec_cpuslocked(&sched_asym_cpucapacity);
>
> rcu_read_lock();
> for_each_cpu(i, cpu_map)
> --
> 2.22.0
prev parent reply other threads:[~2019-10-23 8:46 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-15 15:42 [PATCH v3 0/2] sched/topology: Asymmetric topologies fixes Valentin Schneider
2019-10-15 15:42 ` [PATCH v3 1/2] sched/topology: Don't try to build empty sched domains Valentin Schneider
2019-10-22 11:43 ` Dietmar Eggemann
2019-10-22 12:46 ` Valentin Schneider
2019-10-23 11:46 ` Dietmar Eggemann
2019-10-23 14:12 ` Valentin Schneider
2019-10-15 15:42 ` [PATCH v3 2/2] sched/topology: Allow sched_asym_cpucapacity to be disabled Valentin Schneider
2019-10-23 8:45 ` Dietmar Eggemann [this message]
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=fb378e1c-4b13-5ac4-8c86-8422b5362c7b@arm.com \
--to=dietmar.eggemann@arm.com \
--cc=cgroups@vger.kernel.org \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lizefan@huawei.com \
--cc=mingo@kernel.org \
--cc=morten.rasmussen@arm.com \
--cc=peterz@infradead.org \
--cc=qperret@google.com \
--cc=stable@vger.kernel.org \
--cc=tj@kernel.org \
--cc=valentin.schneider@arm.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 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®