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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <3aec2667-a62d-4a68-ba7d-bad7487dd0f7@arm.com>
Date: Mon, 9 Feb 2026 12:35:26 +0000
From: Lukasz Luba <lukasz.luba@....com>
To: Xuewen Yan <xuewen.yan94@...il.com>, Xuewen Yan <xuewen.yan@...soc.com>
Cc: rafael@...nel.org, daniel.lezcano@...aro.org, rui.zhang@...el.com,
 linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org, ke.wang@...soc.com,
 jeson.gao@...soc.com, di.shen@...soc.com
Subject: Re: [RFC PATCH] thermal: power_allocator: Ignore cutoff when integral
 is less than zero

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