On 1/9/2020 3:46 PM, Daniel Lezcano wrote:
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 <rkumbako@xxxxxxxxxxxxxx>
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?
Yes. We understand IPA could bring down the power/frequency cap multiple
levels compared to step wise which is doing iteratively. With cooling
device weights this makes IPA good for skin temperature control. But
when we evaluated IPA, we found step wise is giving a better performance
compared to IPA for localized junction temperature rules. Additionally,
step wise for the junction temperature rule is easier to tune with fewer
parameters. With these additional enhancements, step wise turned out to
be a better choice for local junction temperature rules.
