linux-kernel - Re: [PATCH] cpufreq: schedutil: govern how frequently we change frequency with rate

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] [day] [month] [year] [list]

Date:   Mon, 20 Feb 2017 15:53:46 +0100
From:   "Rafael J. Wysocki" <rjw@...ysocki.net>
To:     Viresh Kumar <viresh.kumar@...aro.org>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...hat.com>, linaro-kernel@...ts.linaro.org,
        linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org,
        Vincent Guittot <vincent.guittot@...aro.org>
Subject: Re: [PATCH] cpufreq: schedutil: govern how frequently we change frequency with rate_limit

On Monday, February 20, 2017 02:49:18 PM Rafael J. Wysocki wrote:
> On Monday, February 20, 2017 03:28:03 PM Viresh Kumar wrote:
> > On 17-02-17, 13:48, Peter Zijlstra wrote:
> > > On Fri, Feb 17, 2017 at 01:15:56PM +0100, Rafael J. Wysocki wrote:
> > > > On Thursday, February 16, 2017 01:36:05 PM Peter Zijlstra wrote:
> > > > > On Thu, Feb 16, 2017 at 03:42:10PM +0530, Viresh Kumar wrote:
> > > > > > But when I discussed this with Vincent, he suggested that it may not be required
> > > > > > at all as the scheduler (with the helped of "decayed") doesn't call into
> > > > > > schedutil too often, i.e. at least 1 ms. And if the CPUs are stable enough (i.e.
> > > > > > no interruptions to the running task), we wouldn't reevaluate before the next
> > > > > > tick.
> > > > > 
> > > > > There are still the attach/detach callers to cfs_rq_util_change() that
> > > > > kick in for fork/exit and migration.
> > > > > 
> > > > > But yes, barring those we shouldn't end up calling it at silly rates.
> > > > 
> > > > OK
> > > > 
> > > > Does this mean that running governor computations every time its callback
> > > > is invoked by the scheduler would be fine?
> > > 
> > > I'd say yes right up till the point someone reports a regression ;-)
> > 
> > @Rafael: Do you want me to send a V2 with the changes you suggested in
> > commit log?
> 
> Yes, in general, but I have more suggestions regarding that. :-)
> 
> I'll send them shortly.

OK, so I think that the patch subject should be something like "Redefine the
rate_limit_ns" tunable, because that's what really is going on here.

Next, IMO the changelog should say something like this:

"The rate_limit_ns tunable is intended to reduce the possible overhead from
running the schedutil governor.  However, that overhead can be divided into two
separate parts: the governor computations and the invocation of the scaling
driver to set the CPU frequency.  The former is much less expensive in terms of
execution time and running it every time the governor callback is invoked by
the scheduler would not be a problem, so the latter is where the real overhead
comes from.

For this reason, redefine the rate_limit_ns tunable so that it means the
minimum time that has to pass between two consecutive invocations of the
scaling driver by the schedutil governor (to set the CPU frequency)."

Thanks,
Rafael