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

[zhenglifeng (A)]

On 3/17/2026 2:20 PM, Viresh Kumar wrote:
> On 13-03-26, 18:12, zhenglifeng (A) wrote:
>> 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.
> 
> It is fine if you want to do that, just that you should use OS to make that
> change.
> - Update freq table to contain all valid frequencies (1/4 of min in you case).
> - Update policy->min to current min, so you don't go to those low frequencies.
> - Use freq qos or sysfs to change min/max when you want to go really low, like
>   1/4 of min.
> 
>> 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.
> 
> When the OS is kept in the dark about such a change, it needs to figure out a
> way to get back. That's all we are trying here.

I see. Then I think the point is how to let OS know when hardware change the
frequency. It's worth thinking about.

> 
>> 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.
> 
> Exactly the point. We have chosen to do this only when cpufreq core gets to know
> the real frequency. Reading current frequency is a time consuming process and we
> don't want to do it unnecessarily.
> 
>> 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.
> 
> Of course it is a band-aid. No doubt about that. It may not be the best way out,
> but it is how it is right now.
> 

Thanks for the answer.