Re: [PATCH 0/4] CPUFreq statistics retrieved by drivers

[Sudeep Holla <sudeep.holla@arm.com>]

On Thu, Jul 30, 2020 at 02:23:33PM +0530, Viresh Kumar wrote:
> On 29-07-20, 16:12, Lukasz Luba wrote:
> > The existing CPUFreq framework does not tracks the statistics when the
> > 'fast switch' is used or when firmware changes the frequency independently
> > due to e.g. thermal reasons. However, the firmware might track the frequency
> > changes and expose this to the kernel.
> >
> > This patch set aims to introduce CPUfreq statistics gathered by firmware
> > and retrieved by CPUFreq driver. It would require a new API functions
> > in the CPUFreq, which allows to poke drivers to get these stats.
> >
> > The needed CPUFreq infrastructure is in patch 1/4, patch 2/4 extends
> > ARM SCMI protocol layer, patches 3/4, 4/4  modify ARM SCMI CPUFreq driver.
>
> Are you doing this for the fast switch case or because your platform
> actually runs at frequencies which may be different from what cpufreq
> core has requested ?
>

I think so.

> I am also not sure what these tables should represent, what the
> cpufreq core has decided for the CPUs or the frequencies we actually
> run at, as these two can be very different for example if the hardware
> runs at frequencies which don't match exactly to what is there in the
> freq table. I believe these are rather to show what cpufreq and its
> governors are doing with the CPUs.
>

Exactly, I raised similar point in internal discussion and asked Lukasz
to take up the same on the list. I assume it was always what cpufreq
requested rather than what was delivered. So will we break the userspace
ABI if we change that is the main question.

> Over that I would like the userspace stats to work exactly as the way
> they work right now, i.e. capture all transitions from one freq to
> other, not just time-in-state. Also resetting of the stats from
> userspace for example. All allocation and printing of the data must be
> done from stats core, the only thing which the driver would do at the
> end is updating the stats structure and nothing more. Instead of
> reading all stats from the firmware, it will be much easier if you can
> just get the information from the firmware whenever there is a
> frequency switch and then we can update the stats the way it is done
> right now. And that would be simple.
>

Good point, but notifications may not be lightweight. If that is no good,
alternatively, I suggested to keep these firmware stats in a separate
debugfs. Thoughts ?

--
Regards,
Sudeep