Follow up to the LPC2022 discussion around power cooling device

Hi Daniel, Rafael,

Thanks for discussion on LPC around the power & thermal control [1]. Here is the list of known issues which could be used as requirements for this proposed 'power cooling device'. IMO it would be a good place for new approaches how we estimate power. Then we could clean up the cpufreq cooling and devfreq cooling code.

A known design issues from IPA perspective:
1. Input power estimation based on CPU utilization and current CPU frequency. The estimated power can be wrong, especially with schedutil and uclamp when the frequency can be changed in the middle of the IPA period (e.g. 50ms). Also missing accounting of idle time contributes to this. I've sent a proposal how to track better the frequency residency time combined with idle time [2].
2. The maximum allowed frequency (for CPUs and devfreq) can be set by user-space but IPA doesn't know about it and uses the default max value, which is a wrong assumption. The our power budget split is wrong. I've sent some proposal how to get that info into IPA at that time for devfreq only [3].
3. Missing possibility to equpit a HW energy meter, which then could be used for deriving total power for a given IPA period for the cooling device (e.g. CPU cluster or GPU). I have patches internally to address that which could be send to LKML as RFC to EM extension. This would address the problem of different power usage due to different instruction & data mix in the workload.

I can see a good potential to nicely split the work and build a momentum to address those challenges.

Regards,
Lukasz

[1] https://lpc.events/event/16/contributions/1189/
[2] https://lore.kernel.org/linux-pm/[email protected]/
[3] https://lore.kernel.org/all/[email protected]/