On 9/15/20 6:58 PM, Matthias Kaehlcke wrote:
On Tue, Sep 15, 2020 at 07:50:10PM +0200, Daniel Lezcano wrote:
On 15/09/2020 19:24, Matthias Kaehlcke wrote:
+Thermal folks
Hi Rajendra,
On Tue, Sep 15, 2020 at 11:14:00AM +0530, Rajendra Nayak wrote:
Hi Rob,
There has been some discussions on another thread [1] around the DPC (dynamic-power-coefficient) values
for CPU's being relative vs absolute (based on real power) and should they be used to derive 'real' power
at various OPPs in order to calculate things like 'sustainable-power' for thermal zones.
I believe relative values work perfectly fine for scheduling decisions, but with others using this for
calculating power values in mW, is there a need to document the property as something that *has* to be
based on real power measurements?
Relative values may work for scheduling decisions, but not for thermal
management with the power allocator, at least not when CPU cooling devices
are combined with others that specify their power consumption in absolute
values. Such a configuration should be supported IMO.
The energy model is used in the cpufreq cooling device and if the
sustainable power is consistent with the relative values then there is
no reason it shouldn't work.
Agreed on thermal zones that exclusively use CPUs as cooling devices, but
what when you have mixed zones, with CPUs with their pseudo-unit and e.g. a
GPU that specifies its power in mW?
These two (pmW and mW) shouldn't be combined in one thermal
zone with IPA as a governor, but IPA will try to recover.
It will be more unstable meaning the OPPs capping might jump from
lowest to highest, which will be spotted in the testing.
For example, we have CPU with abstract scale where max is 10 and
GPU with real mW max = 2990. They both have the same 'weight' = 1.
Let's say IPA is seeing 3000 as a total budget and splits it:
10/3000 * 3000 = 10
2990/3000 * 3000 = 2990
Which means both actors can run at max speed. Unfortunately, the real
consumption of the CPU could be ~4000mW. The temperature in the next
period will rise above the threshold for which the budget was estimated.
Next time both devices are likely to be capped at minimum freq because
there is no budget and temperature is to high.
After a while the PID would realize this and try to recover, but this
shouldn't be the main solution.
Regards,
Lukasz
