Re: [PATCH v3 0/3] CPUFreq: Add support for cpu performance dependencies

From: Viresh Kumar
Date: Tue Nov 03 2020 - 05:18:49 EST


On 02-11-20, 12:01, Nicola Mazzucato wrote:
> Hi All,
>
> In this V3 posting I have replaced the new dt-binding with minor changes/
> improvements for opp (since we are now using opp tables instead).
> The RFC still stands on how to make this info available to sw consumers.
>
> In the RFC, I am proposing a simple addition of a performance dependencies
> cpumask in CPUFreq core and an example of how drivers and consumers would
> make use of it.
> I also propose an alternative approach, which does not require changes in
> CPUFreq core, but - possibly - in all the consumers.
>
> This is to support systems where exposed cpu performance controls are more
> fine-grained that the platform's ability to scale cpus independently.

I was talking to Vincent about what you are doing here and we got a
bit confused and so here are few questions that we had:

- Based on my previous understanding, you don't want software
coordination of frequencies (which is done by cpufreq today), but
want the hardware to do that and so you want per-cpu cpufreq
policies.

- What's the real benefit of hardware coordination ? Want to make sure
I fully understand that.

- Because of hardware co-ordination of otherwise co-ordinated CPUs,
few things break. Thermal and EAS are some of the examples and so
you are trying to fix them here by proving them the missing
information again.

- One other thing that breaks with this is freq-invariance in the
scheduler, as the scheduler won't see the real frequencies the
various CPUs are running at. Most of the hardware we have today
doesn't have counters, like AMUs, not sure if all future ones based
on SCMI will have that too, so how are they gong to be fixed ?

And if we even have to fix this (freq invariance), what's hardware
coordination giving us that makes all this worth it ?

Sorry about the long list :)

--
viresh