Re: [PATCH 0/2] cpufreq: governor: Apply limits with target_freq instead of policy->cur

["zhenglifeng (A)" <zhenglifeng1@huawei.com>]

On 3/13/2026 2:05 PM, Viresh Kumar wrote:
> On 13-03-26, 11:51, zhenglifeng (A) wrote:
>> When querying cpuinfo_cur_freq, based on the following call chain, the
>> target frequency will eventually be updated if policy->cur is out of
>> limits:
>>
>> show_cpuinfo_cur_freq()
>>   __cpufreq_get()
>>     cpufreq_verify_current_freq()
>>       handle_update()
>>         refresh_frequency_limits()
>>           cpufreq_set_policy()
>>             cpufreq_governor_limits()
>>               cpufreq_dbs_governor_limits()
>>                 cpufreq_policy_apply_limits()
>>                   __cpufreq_driver_target()
>>
>> At least to me, it's strange that querying frequency would cause the
>> target frequency to be updated.
> 
> Yeah, that is an optimization and not a feature. Normally checking the frequency
> shouldn't lead to anything, but cpufreq core needs to fix itself and it actually
> thinks that this won't happen. The hardware (yours) doing something secretly
> isn't right and breaks the design to be honest. One way to fix all this mess is
> to make your platform not do this and instead play with policy->min/max like
> everyone else, instead of making a hard change secretly.
> 

Let's forget what happens on our platform. The current discussion is no
longer about applying this patchset. What I really want to discuss are two
questions:

1. Is the platform allowed to adjust to frequencies out of the limits?

My answer is YES. policy->min and policy->max can be modified by the user.
policy->min can even be increased to be as large as policy->max. However,
due to some other limitations(temperature, power, current etc.), the
platform sometimes has to (secretly as you say) reduce the actual
frequency, inevitably falling below the OS's frequency limits. I believe
this situation will occur not only on our platform. The OS should not treat
this situation as an anomaly, and leading to unpredictable behavior. The OS
should have the ability to self-regulate. I believe that your patch is for
this purpose.

2. Is it reasonable to update the target frequency when querying
cpuinfo_cur_freq?

My answer is NO. The idea that "observation can affect the outcome" should
only apply in quantum mechanics. If querying cpuinfo_cur_freq results in an
update of the target frequency, it means that the target frequency should
indeed be updated, regardless of the query itself. So I think the best
approach is to handle this properly in gov_dbs_update(). But I am not sure
if obtaining the actual frequency in gov_dbs_update() will burden the task.
Perhaps this is why target freq updates are made when querying
cpuinfo_cur_freq now. But this does not mean that it is reasonable. It is
what you call a band-aid I think.

Please let me know if you have a different opinion.