Re: [PATCH 1/2] cpufreq: allow cpuinfo max to decrease when boost is disabled

[Sibi Sankar]

On 8/6/2026 5:42 PM, Dmitry Baryshkov wrote:
> On Thu, Aug 06, 2026 at 03:41:45PM +0530, Sibi Sankar wrote:
> > On 8/6/2026 2:58 PM, Dmitry Baryshkov wrote:
> > > On Thu, Aug 06, 2026 at 10:12:29AM +0530, Sibi Sankar wrote:
> > > > From: Ananthu C V <ananthu.cv@xxxxxxxxxxxxxxxx>
> > > >
> > > > Commit 538b0188da46 ("cpufreq: ACPI: Set cpuinfo.max_freq directly
> > > > if max boost is known") guarded cpuinfo max updates to only allow
> > > > increases, preserving values set directly by drivers above the freq
> > > > table maximum. This prevents cpuinfo max from decreasing on boost
> > > > disable, leaving policy max pinned at the boost ceiling.
> > > Why is this bad?
> > Copy pasting logs shared from the cover letter:
> >
> > # cd /sys/devices/system/cpu/cpufreq/
> > # ls
> > boost  policy0  policy12  policy6
> > # cat boost
> > 0
> > # cat policy6/scaling_max_freq
> > 4454400
> > # echo 1 > boost
> > # cat policy6/scaling_max_freq
> > 4723200
> > # echo 0 > boost
> > # cat policy6/scaling_max_freq
> > 4723200
> How is this different from the maximum frequency being unavailable, for
> example, because of the thermal pressure?

It's certainly different because the maximum frequency is available in this
case. Consider the following scenario where we use the performance
governor with boost disabled -> enabled -> disabled. The governor would
be voting for the max possible frequency, which is the boost frequency even
when boost is explicitly disabled.

# cat boost
0

# cat policy6/scaling_max_freq
4454400

# echo performance > policy6/scaling_governor
# cat policy6/stats/time_in_state
...
4454400 377
4588800 0
4723200 0

# cat policy6/stats/time_in_state
...
4454400 480
4588800 0
4723200 0

# echo 1 > boost
#
#
# cat policy6/stats/time_in_state
...
4454400 951
4588800 0
4723200 200

# echo 0 > boost

# cat policy6/stats/time_in_state
...
4454400 951
4588800 0
4723200 1048

# cat policy6/stats/time_in_state
...
4454400 951
4588800 0
4723200 1115

Shouldn't this behavior be fixed? The boost flag and per-policy boost flag
have no meaning otherwise.

-Sibi

> > Currently disabling boost after enabling it is a NOP,
> > scaling_max freq in this case would be pinned to turbo.
> > It will be reachable through various govenors. Also policy
> > specific boost flag is meaningless unless we have means to
> > reduce the scaling_max_freq.
> >
> > > > Remove the guard so cpuinfo max is always derived from the frequency
> > > > table scan. Drivers that correctly flag boost entries are unaffected
> > > > since the scan already excludes them when boost is off.
> > > >
> > > > Fixes: 538b0188da46 ("cpufreq: ACPI: Set cpuinfo.max_freq directly if max boost is known")
> > > > Signed-off-by: Ananthu C V <ananthu.cv@xxxxxxxxxxxxxxxx>
> > > > Signed-off-by: Sibi Sankar <sibi.sankar@xxxxxxxxxxxxxxxx>
> > > > ---
> > > >    drivers/cpufreq/freq_table.c | 7 +------
> > > >    1 file changed, 1 insertion(+), 6 deletions(-)