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  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, 17 Feb 2017 13:15:56 +0100
From:   "Rafael J. Wysocki" <>
To:     Peter Zijlstra <>
Cc:     Viresh Kumar <>,
        Ingo Molnar <>,,,,
        Vincent Guittot <>
Subject: Re: [PATCH] cpufreq: schedutil: govern how frequently we change frequency with rate_limit

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.


Does this mean that running governor computations every time its callback
is invoked by the scheduler would be fine?


Powered by blists - more mailing lists