On 7/14/21 7:30 PM, Rafael J. Wysocki wrote:

Sorry for the delay.

Thank you for coming back with comments.
No worries, I've been on holidays last week :)

[snip]

quoted

quoted

quoted

I understand your concerns. If you have another idea than this framework
I'm happy to hear it. Maybe better stats in cpuidle, which would be
are of the cpufreq?

One idea that I have is outlined above and I'm not seeing a reason to
put cpufreq statistics into cpuidle.

I'm happy to prepare such RFC if you like.

Well, it should be quite clear that I would prefer this to the
original approach, if viable at all. :-)

Sure, let me check if this approach is viable. I'll come back to you
in next days...

quoted

I would just need a bit more information.

OK

For now I have only high level questions:
1. The stats data structures and related manageable code should
live in the cpuidle and cpufreq just calls some API to notify about
freq transition? (no split of data, code between these two frameworks)
2. The registration/allocation of these structures inside the
cpuidle could be done using cpufreq_register_notifier() with
notification mechanism?
3. CPU hotplug notification (which is needed for these stats) can be
used inside the cpuidle (cpuhp_setup_state(CPUHP_AP_ONLINE_DYN,...))?