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

[Lukasz Luba <lukasz.luba@arm.com>]

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@unisoc.com> wrote:
>>
>> From: Jeson Gao <jeson.gao@unisoc.com>
>>
>> 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@unisoc.com>
>> Signed-off-by: Di Shen <di.shen@unisoc.com>
>> Signed-off-by: Jeson Gao <jeson.gao@unisoc.com>
>> Signed-off-by: Xuewen Yan <xuewen.yan@unisoc.com>
>> ---
>>   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 for reporting this issue!

Regards,
Lukasz