Re: [PATCH 4/4] cpu_cooling: Drop static-power related stuff

[Eduardo Valentin]

Hello folks,

On Tue, Nov 21, 2017 at 05:08:34PM +0100, Vincent Guittot wrote:
> Hi Lukasz
> 
> On 21 November 2017 at 16:56, Lukasz Luba <llu.ker.dev@xxxxxxxxx> wrote:
> > On 21/11/17 14:06, Daniel Lezcano wrote:
> >>
> >> On 21/11/2017 12:30, Ionela Voinescu wrote:
> >>
> >> [ ... ]
> >>
> >>> A DT model would be easy to support with the current code but it would
> >>> be very inaccurate.
> >>
> >>
> >> Why ?
> >>
> >> [ ... ]
> >>
> > Hi all,
> >
> > The DT solution won't fly, the reason can be found below.

The APIs being removed by this patch is exactly to cover for the
difficulty to model all static power cases. 


> >
> > I agree with Ionela and Punit that the Juno board is not
> > the best platform to test the static power impact on IPA.
> > In some other platforms the static power can be 50% or more
> > of the total power, so it cannot be neglected.
> >
> > These are the issues.
> > The static power equation is complicated, here is one known to me.
> > The leakage function is exponentially influenced by current circuit
> > supply voltage, body-bias and some constants K_{4,5}.
> >
> > P_{leak} = L_{g}*V_{dd}*K_{3}*e^{K_{4}*V_{dd}}*e^{K_{5}*V_{bs}}+|
> > V_{bs}|*I_{Ju}
> 
> You forgot one main contributor of static leakage: the temperature
> 


We all agree that it is hard to model static power, specially
considering all variables. And that today, ARM/Linaro failed to
convince vendors to expose this in mainline. So, ...

> >
> > It can also vary depending on technology (CMOS, FinFET, etc).
> >
> > It would be really hard to approximate by i.e. a polynomial
> > function with inputs from DT. One size does not fit all.
> 
> But can't we linearized around the target temp ? that were we want to
> be accurate
> 
> Regards,
> >
> > The equation can also tell you some interesting things about
> > the manufacturing process. Exposing such information might be the last
> > thing the vendors want to.
> > That's why the vendors might want to implement whole
> > thermal management in the firmware or skip static power and
> > rely on IPA adaptation.
> > They can also use a different api in IPA, when they have some mechanism
> > to measure power in firmware, it can be feed into IPA.
> >


The lack of code in mainline, is not really because the API would not
help IPA, but because 2.5y after this has been merged, vendors were not
convinced to push a model, even if simple, to mainline.

> > Anyway, I would recommend to keep it as is, to have a complete
> > power model in the kernel.
> > The code without static power routines looks awkward to me.
> > From my side - NACK for the patch which removes static power.
> >


However, we cannot NACK just because we like the code :-). Nor we can
NACK because vendors keep their code in Android tree somewhere, or in
any other tree. Viresh has a point, if one looks at this code today in
mainline, no one is using, it is a dead code, doesn't matter what is out
of the tree using it.

As I said before, the minimal you guys (ARM and Linaro) can do is to at
least upstream the Juno code! as a reference. Come on guys?  what is
preventing you to upstream Juno model? As already discussed in this
thread, we know Juno won't be the best platform to benefit for it, but
it has a static power component, and for sure behaves better with the
static power model than only with dynamic power.

> > Regards,
> > Lukasz Luba