Re: [PATCH] cpufreq: conservative: Fix incorrect frequency decrease due to stale target

[Zhongqiu Han <zhongqiu.han@oss.qualcomm.com>]

On 4/21/2026 8:35 PM, Lifeng Zheng wrote:
> In cs_dbs_update(), the requested frequency is decremented by one freq_step
> for each idle period. However, this can cause divergence between
> 'requested_freq' (target for current update) and 'dbs_info->requested_freq'
> (target from previous update).
> 
> When the load crosses up_threshold or down_threshold, the decision on
> whether to increase or decrease frequency should be based on the *previous*
> target (dbs_info->requested_freq), not the current one. Otherwise, the
> update step may be skipped entirely if the current target has already hit a
> boundary due to prior adjustments.
> 
> Ensure that frequency scaling decisions are made using the correct
> historical target, fixing cases where frequency fails to decrease despite
> sustained idle periods.
> 
> Fixes: 00bfe05889e9 ("cpufreq: conservative: Decrease frequency faster for deferred updates")
> Signed-off-by: Lifeng Zheng <zhenglifeng1@huawei.com>

Hi Lifeng,
Thanks for the patch.

May I know would this ignore conservative idle decay when the previous
requested frequency was policy->max?


Scenario: Increase path, previous target at max, with idle
compensation; the original code does not have the same behavior as the
current patch.

Initial state:
   policy->max               = 2000 MHz
   policy->min               = 200 MHz
   dbs_info->requested_freq  = 2000 MHz  (= policy->max)
   hardware frequency        = 2000 MHz
   idle_periods              = 2
   load                      = 90% (> up_threshold=80)

1.Original code
Step 1: requested_freq = dbs_info->requested_freq = 2000

Step 2: [idle_periods block]
         freq_steps = 2 * 100 = 200
         2000 > (200 + 200) = 400 ?  YES
         requested_freq = 2000 - 200 = 1800
Step 3: [increase path]
         if (requested_freq == policy->max)
           -> 1800 == 2000 ?  NO  -> fall through

Step 4: requested_freq += freq_step
         requested_freq = 1800 + 100 = 1900

Step 5: __cpufreq_driver_target(policy, 1900, HE) -> hardware = 1900 MHz
Step 6: dbs_info->requested_freq = 1900

Result: hardware 2000 -> *1900 MHz* (net 1-step decrease)


2.Current Patch
Step 1: requested_freq = 2000
Step 2: [idle_periods block] -> requested_freq = 1800
Step 3: if (dbs_info->requested_freq == policy->max)
           -> 2000 == 2000 ?  YES  -> goto out
Step 4: hardware stays at 2000 MHz, dbs_info->requested_freq stays at 2000

Result: hardware stays at *2000 MHz* (no change)




> ---
>   drivers/cpufreq/cpufreq_conservative.c | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/cpufreq/cpufreq_conservative.c b/drivers/cpufreq/cpufreq_conservative.c
> index df01d33993d8..f3c3b54e4bf8 100644
> --- a/drivers/cpufreq/cpufreq_conservative.c
> +++ b/drivers/cpufreq/cpufreq_conservative.c
> @@ -104,7 +104,7 @@ static unsigned int cs_dbs_update(struct cpufreq_policy *policy)
>   		dbs_info->down_skip = 0;
>   
>   		/* if we are already at full speed then break out early */
> -		if (requested_freq == policy->max)
> +		if (dbs_info->requested_freq == policy->max)
>   			goto out;
>   
>   		requested_freq += freq_step;
> @@ -127,7 +127,7 @@ static unsigned int cs_dbs_update(struct cpufreq_policy *policy)
>   		/*
>   		 * if we cannot reduce the frequency anymore, break out early
>   		 */
> -		if (requested_freq == policy->min)
> +		if (dbs_info->requested_freq == policy->min)
>   			goto out;
>   
>   		if (requested_freq > freq_step)


-- 
Thx and BRs,
Zhongqiu Han