Re: [PATCH] drivers: thermal: step_wise: add support for hysteresis

[Amit Kucheria <amit.kucheria@linaro.org>]

On Thu, Nov 21, 2019 at 7:40 PM Thara Gopinath
<thara.gopinath@linaro.org> wrote:
>
> On 11/21/2019 12:50 AM, Amit Kucheria wrote:
> > From: Ram Chandrasekar <rkumbako@codeaurora.org>
> >
> > Currently, step wise governor increases the mitigation when the
> > temperature goes above a threshold and decreases the mitigation when the
> > temperature goes below the threshold. If there is a case where the
> > temperature is wavering around the threshold, the mitigation will be
> > applied and removed every iteration, which is not very efficient.
> >
> > The use of hysteresis temperature could avoid this ping-pong of
> > mitigation by relaxing the mitigation to happen only when the
> > temperature goes below this lower hysteresis value.
> Hi Amit,
>
> Can this not lead to ping-pong around the hysteresis temperature?

That isn't how hysteresis is supposed to work if there is a sufficient
delta between your trip point and your hysteresis value.

e.g. if you have a trip at 80C and a hysteresis of 10C, it means that
you will start throttling at 80C, but you won't STOP throttling until
you cool down to 70C. At that point, you will wait again to get to 80C
before throttling again.
IOW, on the downward slope (80 -> 70) you still have throttling active
and on the upward slope (70 -> 80), you have no[1] throttling, so
different behaviour is the same temperature range depending on
direction.

If your hysteresis value was very low .e.g. 1C, it would certainly be useless.

> If the idea is to minimize ping-pong isn't average a better method?

We shouldn't ping-pong with the asymmetric behaviour described above.

Regards,
Amit
[1] This is a simple example with a single trip point.