[lkml]   [2020]   [Jan]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] drivers: thermal: step_wise: add support for hysteresis
On 08/01/2020 01:31, Ram Chandrasekar wrote:
> On 12/11/2019 6:35 AM, Daniel Lezcano wrote:
>> On 21/11/2019 06:50, Amit Kucheria wrote:
>>> From: Ram Chandrasekar <>
>>> 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.
>> What I'm worried about is how the hysteresis is used in the current
>> code, where the destination of this data is to set the value in the
>> sensor hardware if it is supported.
>> Using the hysteresis in the governor seems like abusing the initial
>> purpose of this information.
>> Moreover, the hysteresis creates a gray area where the above algorithm
>> (DROPPING && !throttle) => state-- or (RAISING && throttle) => state++
>> may drop the performances because we will continue mitigating even below
>> the threshold.
>> As the governor is an open-loop controller, I'm not sure if we can do
>> something except adding some kind of low pass filter to prevent
>> mitigation bounces.
> We have two different use cases for the step wise algorithm, and the
> hysteresis makes sense only in one.
> For example, say we are controlling CPU junction temperature at 95C.
> When using step wise, mitigation is applied iteratively and there is a
> possibility that temperature can shoot up before the algorithm can reach
> an optimal mitigation level to keep the temperature near threshold.
> In order to help this state machine, we use a second back stop rule in
> the same thermal zone at a higher temperature (say 105C) with a
> hysteresis of 10C to mitigate CPU to a fixed value, by specifying
> upper/lower limit to be the same. The idea is that the second rule will
> place a hard hammer to bring the temperature down close to 95C and then
> it will remove the mitigation. Once mitigation is removed, the junction
> temperature rule state machine will re-adjust from that point to an
> optimal mitigation level. The junction temperature rule doesn’t use
> hysteresis.
> Another example is skin temperature mitigation for mobile devices, where
> the step wise algorithm with hysteresis just reduces the operating max
> frequency to a fixed value, when the threshold is reached. And the
> junction temperature rule starts mitigating from this operating max.
> That is the reason we have not generalized or mandated the hysteresis
> usage in this patch. The idea is to use it selectively based on use case.

Did you ever try the IPA governor?

<> │ Open source software for ARM SoCs

Follow Linaro: <> Facebook |
<!/linaroorg> Twitter |
<> Blog

 \ /
  Last update: 2020-01-09 23:46    [W:1.269 / U:15.332 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site