Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

[Viresh Kumar]

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
> that.
> 
> 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 :)

-- 
viresh