Re: is 'dynamic-power-coefficient' expected to be based on 'real' power measurements?

[Matthias Kaehlcke <mka@chromium.org>]

On Wed, Sep 16, 2020 at 09:45:04AM +0530, Rajendra Nayak wrote:
> 
> On 9/16/2020 3:06 AM, Matthias Kaehlcke wrote:
> > On Tue, Sep 15, 2020 at 11:23:49PM +0200, Daniel Lezcano wrote:
> > > On 15/09/2020 23:13, Matthias Kaehlcke wrote:
> > > > On Tue, Sep 15, 2020 at 10:55:52PM +0200, Daniel Lezcano wrote:
> > > > > On 15/09/2020 19:58, 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?
> > > > > 
> > > > > Well, if a SoC vendor decides to mix the units, then there is nothing we
> > > > > can do.
> > > > > 
> > > > > When specifying the power numbers available for the SoC, they could be
> > > > > all scaled against the highest power number.
> > > > 
> > > > The GPU was just one example, a device could have heat dissipating components
> > > > that are not from the SoC vendor (e.g. WiFi, modem, backlight), and depending
> > > > on the design it might not make sense to have separate thermal zones.
> > > 
> > > Is it possible to elaborate, I'm not sure to get the point ?
> > 
> > A device could have a thermal zone with the following cooling
> > devices:
> > 
> > - CPUs with power consumption specified as pmW (pseudo mW
> > - A modem from a third party vendor. The modem can dissipate
> >    significant heat and allows to throttle the bandwidth for
> >    cooling. The power consumption of the modem is given in
> >    mW.
> > 
> > These could be crammed together in a small form factor
> > (e.g. ChromeCast or Chromebit) which makes it difficult to
> > discern with a sensor what exactly is generating the heat,
> > which is why you have a single thermal zone.
> > 
> > IPA is used as governor for this zone, it can't make accurate
> > decisions because one cooling device specifies it's power
> > consumption in pmW and the other in mW.
> 
> Is there a real example upstream for this, or is it a theoretical
> problem (which can exist in the future) we are trying to solve?

Sort of, there is the rk3288-based veyron-mickey, which uses CPUs,
the GPU and ddrfreq as cooling devices in the same zone:

https://chromium.googlesource.com/chromiumos/third_party/kernel/+/refs/heads/chromeos-4.19/arch/arm/boot/dts/rk3288-veyron-mickey.dts#42

The device doesn't use IPA though, so mixed up units wouldn't matter in this
case.

From a quick grep in arch/arm(64)/boot/dts/ at least it seems that mixing
cooling devices of different types is not a common case, though it doesn't
necessarily reflect what is done in custom DTs.