Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support
From: Dietmar Eggemann
Date: Mon Jul 10 2017 - 06:31:43 EST
On 10/07/17 10:42, Viresh Kumar wrote:
> On 10-07-17, 11:30, Peter Zijlstra wrote:
>> On Sat, Jul 08, 2017 at 02:09:37PM +0200, Rafael J. Wysocki wrote:
>>> Anyway, if everyone agrees that doing it in the core is the way to go (Peter?),
>>> why don't you introduce a __weak function for setting policy->cur and
>>> override it from your arch so as to call arch_set_freq_scale() from there?
>> So I'm terminally backlogged and my recent break didn't help any with
>> I'm at a total loss as to what is proposed here and why we need it. I
>> tried reading both the Changelog and patch but came up empty.
> Dietmar is proposing the implementation of arch_set_freq_scale() for ARM (32/64)
> platforms here with following equation in drivers/base/arch_topology.c:
> scale = (cur_freq << SCHED_CAPACITY_SHIFT) / max_freq
> The only variable part here is "cur_freq" and he is looking for sane ways to get
> that value in the arch_topology.c file, so he can use that in the above
> equation. He tried to use cpufreq transition notifiers earlier but they block us
> from using fast switching.
> What he is proposing now is a function:
> void arch_set_freq_scale(struct cpumask *cpus, unsigned long cur_freq,
> unsigned long max_freq);
> which has to be called by someone after the frequency of the CPU is changed.
> Dietmar proposed that this be called by cpufreq core and Rafael was wondering if
> the cpufreq drivers should call it. Dietmar's argument is that it will be used
> for the entire ARM architecture this way and wouldn't lead to redundant core
> across drivers.
> Hope I didn't confuse you more with this :)
Perfect summary, thanks Viresh!
This is required for architectures (like arm/arm64) which do not have
any other way to know about the current CPU frequency.
X86 can do the frequency invariance support based on APERF/MPERF already
today so it does not need the support from cpufreq.