Re: [RFC PATCH] thermal: power_allocator: Ignore cutoff when integral is less than zero

[Xuewen Yan]

On Mon, Feb 9, 2026 at 8:35 PM Lukasz Luba <lukasz.luba@xxxxxxx> wrote:
>
> Hi Xuewen,
>
> On 1/26/26 03:24, Xuewen Yan wrote:
> > Hi lukasz,
> >
> > Do you have any comments on this patch?
>
> I missed that patch, my apologies.
>
> >
> > Thanks!
> >
> > On Mon, Jan 19, 2026 at 10:00 AM Xuewen Yan <xuewen.yan@xxxxxxxxxx> wrote:
> >>
> >> From: Jeson Gao <jeson.gao@xxxxxxxxxx>
> >>
> >> The cutoff means threshold below which the error is no longer accumulated.
> >> However, in some scenarios, this may cause performance degradation.
> >>
> >> For example:
> >> the control-temp is 85, the cutoff is 0 or other small value:
> >>
> >> If the current temperature frequently exceeds the set temperature,
> >> the negative integral will continuously accumulate.
> >> Over an extended period, this will result in a significantly
> >> large negative integral value, the positive integral can’t build up
> >> because of the cutoff. This makes the power_range very low,
> >> even if the temperature is already under the control target.
> >>
> >> So, if the err_integral is negative, ignore the cutoff to force
> >> add the positive integral.
>
> The accumulated Integral in the PID works like that, so no surprise
> here (the math is correct). The Integral part tires to 'compensate'
> the previous 'mistakes', e.g. slow down the rapid change which
> has been seen and caused the overshoot.
>
> >>
> >> Co-developed-by: Di Shen <di.shen@xxxxxxxxxx>
> >> Signed-off-by: Di Shen <di.shen@xxxxxxxxxx>
> >> Signed-off-by: Jeson Gao <jeson.gao@xxxxxxxxxx>
> >> Signed-off-by: Xuewen Yan <xuewen.yan@xxxxxxxxxx>
> >> ---
> >>   drivers/thermal/gov_power_allocator.c | 3 ++-
> >>   1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/thermal/gov_power_allocator.c b/drivers/thermal/gov_power_allocator.c
> >> index 0d9f636c80f4..404ae1d75612 100644
> >> --- a/drivers/thermal/gov_power_allocator.c
> >> +++ b/drivers/thermal/gov_power_allocator.c
> >> @@ -263,7 +263,8 @@ static u32 pid_controller(struct thermal_zone_device *tz,
> >>           */
> >>          i = mul_frac(tz->tzp->k_i, params->err_integral);
> >>
> >> -       if (err < int_to_frac(tz->tzp->integral_cutoff)) {
> >> +       if (err < int_to_frac(tz->tzp->integral_cutoff) ||
> >> +           (err > 0 && params->err_integral < 0)) {
> >>                  s64 i_next = i + mul_frac(tz->tzp->k_i, err);
> >>
> >>                  if (abs(i_next) < max_power_frac) {
> >> --
> >> 2.25.1
> >>
>
> Although, I might probably know where you're coming from and what you
> are trying to achieve (what is your platform's situation). Let me do
> some simulations based on what you've described. I will look into
> those signals in those conditions.
>
> At the moment, I'm a bit afraid about your proposed simple change
> and possible impact to other platforms.
> Let me do my research and come back.

Thank you very much for your reply! We would also be happy to
participate in testing your follow-up research. Thanks again!

BR

---
xuewen

>
> Thank you for reporting this issue!
>
> Regards,
> Lukasz