On Fri, 19 Feb 2021 13:12:49 +0530
Viresh Kumar [off-list ref] wrote:

On 19-02-21, 14:41, Yue Hu wrote:

quoted

On Fri, 19 Feb 2021 09:39:33 +0530
Viresh Kumar [off-list ref] wrote:
  

quoted

On 19-02-21, 11:38, Yue Hu wrote:  

quoted

There's a possibility: we will use the previous freq to update
if next_f is reduced for busy CPU if need_freq_update is set in
sugov_update_next_freq().    

Right.
  

quoted

This possibility would happen now? And this
update is what we want if it happens?    

This is exactly what we want here, don't reduce speed for busy
CPU,  

I understand it should not skip this update but set the same freq as
previous one again for the special case if need_freq_update is set.
Am i rt?  

The special check, about not reducing freq if CPU had been busy
recently, doesn't have anything to do with need_freq_update.

However, we will skip the update if need_freq_update is not set. And do
the update if need_freq_update is set.

Note that there are unnecessary fast switch check and spin lock/unlock
operations in freq skip path.

If we consider unnecessary behaviors above, then we should return right
away rather than continue to execute following code.

Consequently, we also need to consider need_update_freq flag since we
need to update freq currently if it is set.

Though previously we added the need_freq_update check there to make
sure we account for any recent policy min/max change and don't skip
freq update anymore. That won't happen anymore and so we don't need
any check here related to need_freq_update.

If you still have doubt, please explain your concern in detail with an
example as I am failing to understand it.