linux-kernel - Re: [PATCH] cpufreq: schedutil: Don't consider freq reduction to busy CPU if need_freq

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 19 Feb 2021 16:20:26 +0800
From:   Yue Hu <zbestahu@...il.com>
To:     Viresh Kumar <viresh.kumar@...aro.org>
Cc:     rjw@...ysocki.net, mingo@...hat.com, peterz@...radead.org,
        juri.lelli@...hat.com, vincent.guittot@...aro.org,
        dietmar.eggemann@....com, rostedt@...dmis.org, bsegall@...gle.com,
        linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org,
        huyue2@...ong.com, zbestahu@....com
Subject: Re: [PATCH] cpufreq: schedutil: Don't consider freq reduction to
 busy CPU if need_freq_update is set

On Fri, 19 Feb 2021 13:12:49 +0530
Viresh Kumar <viresh.kumar@...aro.org> wrote:

> On 19-02-21, 14:41, Yue Hu wrote:
> > On Fri, 19 Feb 2021 09:39:33 +0530
> > Viresh Kumar <viresh.kumar@...aro.org> wrote:
> >   
> > > On 19-02-21, 11:38, Yue Hu wrote:  
> > > > 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.
> > >   
> > > > 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.
>