From: Ionela Voinescu <ionela.voinescu@arm.com>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
Vincent Guittot <vincent.guittot@linaro.org>
Subject: Re: [PATCH] arm64: topology: Cleanup init_amu_fie() a bit
Date: Thu, 10 Dec 2020 10:38:15 +0000 [thread overview]
Message-ID: <20201210103815.GA3313@arm.com> (raw)
In-Reply-To: <5594c7d6756a47b473ceb6f48cc217458db32ab0.1607584435.git.viresh.kumar@linaro.org>
Hi,
On Thursday 10 Dec 2020 at 12:48:20 (+0530), Viresh Kumar wrote:
> Every time I have stumbled upon this routine, I get confused with the
> way 'have_policy' is used and I have to dig in to understand why is it
> so.
>
I'm first of all replying to discuss the need of this policy analysis
that enable_policy_freq_counters() does which results in the setting of
have_policy.
Basically, that's functions purpose is only to make sure that invariance
at the level of the policy is consistent: either all CPUs in a policy
support counters and counters will be used for the scale factor, or
either none or only some support counters and therefore the default
cpufreq implementation will be used (arch_set_freq_scale()) for all CPUs
in a policy.
If we find that cpufreq policies are not present at all, we only enable
counter use if all CPUs support them.
This being said, there is a very important part of your patches in this
set:
+ /* Disallow partial use of counters for frequency invariance */
+ if (!cpumask_equal(amu_fie_cpus, cpu_present_mask))
+ goto free_valid_mask;
If this is agreed upon, there is a lot more that can be removed from the
initialisation: enable_policy_freq_counters() can entirely go away plus
all the checks around it.
I completely agree that all of this will be more clear if we decided to
"Disallow partial use of counters for frequency invariance", but I think
we might have to add it back in again when systems with partial support
for counters show up.
I don't agree to not support these systems from the get go as it's
likely that the first big.LITTLE systems will only have partial support
for AMUs, but it's only an assumption at this point.
I'm happy to hear the opinion of other arm64 folk about this.
Many thanks for looking over the code,
Ionela.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-12-10 10:39 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-10 7:18 [PATCH] arm64: topology: Cleanup init_amu_fie() a bit Viresh Kumar
2020-12-10 9:42 ` [PATCH] arm64: topology: Avoid the static_branch_{enable|disable} dance Viresh Kumar
2020-12-10 11:09 ` Ionela Voinescu
2020-12-10 12:35 ` Viresh Kumar
2020-12-10 10:34 ` [PATCH] arm64: topology: Cleanup init_amu_fie() a bit Viresh Kumar
2020-12-10 10:38 ` Ionela Voinescu [this message]
2020-12-10 10:55 ` Viresh Kumar
2020-12-10 11:29 ` Ionela Voinescu
2020-12-10 12:34 ` Viresh Kumar
2020-12-10 13:26 ` Ionela Voinescu
2020-12-11 11:05 ` Viresh Kumar
2020-12-14 16:14 ` Ionela Voinescu
2020-12-10 13:22 ` Ionela Voinescu
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=20201210103815.GA3313@arm.com \
--to=ionela.voinescu@arm.com \
--cc=catalin.marinas@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=vincent.guittot@linaro.org \
--cc=viresh.kumar@linaro.org \
--cc=will@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).