From: Viresh Kumar <viresh.kumar@linaro.org>
To: Ionela Voinescu <ionela.voinescu@arm.com>
Cc: Juri Lelli <juri.lelli@redhat.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Catalin Marinas <catalin.marinas@arm.com>,
"open list:THERMAL" <linux-pm@vger.kernel.org>,
Sudeep Holla <sudeep.holla@arm.com>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
linux-kernel <linux-kernel@vger.kernel.org>,
Steven Rostedt <rostedt@goodmis.org>,
Ben Segall <bsegall@google.com>, Ingo Molnar <mingo@redhat.com>,
Mel Gorman <mgorman@suse.de>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Peter Puhov <peter.puhov@linaro.org>,
Will Deacon <will@kernel.org>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
LAK <linux-arm-kernel@lists.infradead.org>
Subject: Re: [RFC 0/3] cpufreq: cppc: Add support for frequency invariance
Date: Mon, 31 Aug 2020 16:56:38 +0530 [thread overview]
Message-ID: <20200831112638.v6vyljefggptij2v@vireshk-i7> (raw)
In-Reply-To: <20200827112740.GA9923@arm.com>
On 27-08-20, 12:27, Ionela Voinescu wrote:
> I don't see it as anyone registering for freq invariance, rather the
> freq invariance framework chooses its source of information (AMU, CPPC,
> cpufreq).
Yeah, either way is fine for me.
> > i.e. if CPPC registers for it first then there is no need to check
> > AMUs further (as CPPC will be using AMUs anyway), else we will
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Not necessarily. Even if AMUs are present, they are only used for CPPC's
> delivered and reference performance counters if the ACPI _CPC entry
> specifies FFH as method:
>
> ResourceTemplate(){Register(FFixedHW, 0x40, 0, 1, 0x4)},
> ResourceTemplate(){Register(FFixedHW, 0x40, 0, 0, 0x4)},
Right.
> While I understand your point (accessing AMUs through CPPC's read
> functions to implement invariance) I don't think it's worth tying the
> two together.
>
> I see the two functionalities as independent:
> - frequency invariance with whichever source of information is valid
> (AMUs, cpufreq, etc) is separate from
> - CPPC's delivered and reference performance counters, which currently
> are used in cpufreq's .get() function.
>
> Therefore, taking each of the scenarios one by one:
> - All CPUs support AMUs: the freq invariance initialisation code will
> find AMUs valid and it will use them to set the scale factor;
> completely independently, if the FFH method is specified for CPPC's
> delivered and reference performance counters, it will also use
> AMUs, even if, let's say, invariance is disabled.
>
> - None of the CPUs support AMUs, but the _CPC entry specifies some
> platform specific counters for delivered and reference performance.
> With the current mainline code neither cpufreq or counter based
> invariance is supported, but the CPPC counters can be used in the
> cppc_cpufreq driver for the .get() function.
>
> But with the above new functionality we can detect that AMUs are not
> supported and expose the CPPC counters to replace them in
> implementing invariance.
>
> - Mixed scenarios are also supported if we play our cards right and
> implement the above per-cpu.
>
>
> I'm thinking that having some well defined invariance sources might work
> well: it will simplify the init function (go through all registered
> sources and choose (per-cpu) the one that's valid) and allow for
> otherwise generic invariance support. Something like:
>
> enum freq_inv_source {INV_CPUFREQ, INV_AMU_COUNTERS, INV_CPPC_COUNTERS};
>
> struct freq_inv_source {
> enum freq_inv_source source;
> bool (*valid)(int cpu);
> u64 (*read_corecnt)(int cpu);
> u64 (*read_constcnt)(int cpu);
> u64 (*max_rate)(int cpu);
> u64 (*ref_rate)(int cpu);
> }
>
> I am in the middle of unifying AMU counter and cpufreq invariance through
> something like this, so if you like the idea and you don't think I'm
> stepping too much on your toes with this, I can consider the usecase in
> my (what should be) generic support. So in the end this might end up
> being just a matter of adding a new invariance source (CPPC counters).
Okay, if you have already started working on that, no issues from my
side. I can just get the relevant stuff from CPPC added once you
provide that layer..
> My only worry is that while I know how a cpufreq source behaves and how
> AMU counters behave, I'm not entirely sure what to expect from CPPC
Neither do I :)
> counters: if they are always appropriate for updates on the tick (not
> blocking),
The update stuff may sleep here and so I had to do stuff in the
irq-work handler in my patch.
> if they both stop during idle, if there is save/restore
> functionality before/after idle, etc.
This I will check.
--
viresh
_______________________________________________
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-08-31 11:28 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-09 10:13 [RFC 0/3] cpufreq: cppc: Add support for frequency invariance Viresh Kumar
2020-07-09 10:13 ` [RFC 1/3] arm64: topology: Add amu_counters_supported() helper Viresh Kumar
2020-07-09 10:13 ` [RFC 2/3] topology: Provide generic implementation of arch_freq_counters_available() Viresh Kumar
2020-07-09 12:43 ` [RFC 0/3] cpufreq: cppc: Add support for frequency invariance Ionela Voinescu
2020-07-10 3:00 ` Viresh Kumar
2020-07-24 9:38 ` Vincent Guittot
2020-08-24 10:49 ` Viresh Kumar
2020-08-25 9:56 ` Ionela Voinescu
2020-08-27 7:51 ` Viresh Kumar
2020-08-27 11:27 ` Ionela Voinescu
2020-08-31 11:26 ` Viresh Kumar [this message]
2020-10-05 7:58 ` Viresh Kumar
2020-10-05 23:16 ` 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=20200831112638.v6vyljefggptij2v@vireshk-i7 \
--to=viresh.kumar@linaro.org \
--cc=bsegall@google.com \
--cc=catalin.marinas@arm.com \
--cc=dietmar.eggemann@arm.com \
--cc=gregkh@linuxfoundation.org \
--cc=ionela.voinescu@arm.com \
--cc=juri.lelli@redhat.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=peter.puhov@linaro.org \
--cc=peterz@infradead.org \
--cc=rafael@kernel.org \
--cc=rjw@rjwysocki.net \
--cc=rostedt@goodmis.org \
--cc=sudeep.holla@arm.com \
--cc=vincent.guittot@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).