From: Valentin Schneider <valentin.schneider@arm.com>
To: Quentin Perret <qperret@google.com>
Cc: Vincent Guittot <vincent.guittot@linaro.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
Ingo Molnar <mingo@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Dietmar Eggemann <Dietmar.Eggemann@arm.com>,
Morten Rasmussen <morten.rasmussen@arm.com>,
Quentin Perret <qperret@qperret.net>,
"# v4 . 16+" <stable@vger.kernel.org>
Subject: Re: [PATCH] sched/topology: Disable sched_asym_cpucapacity on domain destruction
Date: Mon, 14 Oct 2019 17:03:27 +0100 [thread overview]
Message-ID: <2b058430-1951-3d58-ebf4-8195a28ff233@arm.com> (raw)
In-Reply-To: <20191014135256.GA85340@google.com>
On 14/10/2019 14:52, Quentin Perret wrote:
> Right, but that's not possible by definition -- static keys aren't
> variables. The static keys for asym CPUs and for EAS are just to
> optimize the case when they're disabled, but when they _are_ enabled,
> you have no choice but do another per-rd check.
>
Bleh, right, realized my nonsense after sending the email.
> And to clarify what I tried to say before, it might be possible to
> 'count' the number of RDs that have SD_ASYM_CPUCAPACITY set using
> static_branch_inc()/dec(), like we do for the SMT static key. I remember
> trying to do something like that for EAS, but that was easier said than
> done ... :)
>
Gotcha, the reason I didn't go with this is that I wanted to maintain
the relationship between the key and the flag (you either have both or none).
It feels icky to have the key set and to have a NULL sd_asym_cpucapacity
pointer.
An alternative might be to have a separate counter for asymmetric rd's,
always disable the key on domain destruction and use that counter to figure
out if we need to restore it. If we don't care about having a NULL SD
pointer while the key is set, we could use the included counter as you're
suggesting.
> Thanks,
> Quentin
>
next prev parent reply other threads:[~2019-10-14 16:03 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-14 11:47 Valentin Schneider
2019-10-14 11:52 ` Vincent Guittot
2019-10-14 12:16 ` Quentin Perret
2019-10-14 13:29 ` Vincent Guittot
2019-10-14 13:46 ` Valentin Schneider
2019-10-14 13:52 ` Quentin Perret
2019-10-14 16:03 ` Valentin Schneider [this message]
2019-10-15 9:22 ` Dietmar Eggemann
2019-10-15 9:47 ` Valentin Schneider
2019-10-15 11:07 ` Quentin Perret
2019-10-15 12:56 ` Dietmar Eggemann
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=2b058430-1951-3d58-ebf4-8195a28ff233@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=peterz@infradead.org \
--cc=qperret@google.com \
--cc=qperret@qperret.net \
--cc=stable@vger.kernel.org \
--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®