linux-kernel - Re: [RFC V2 1/6] cpufreq: Replace "max_transition_latency" with "dynamic

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]

Message-ID: <2309380.IRBF8BkiFH@aspire.rjw.lan>
Date:   Sat, 15 Jul 2017 00:06:24 +0200
From:   "Rafael J. Wysocki" <rjw@...ysocki.net>
To:     "Rafael J. Wysocki" <rafael@...nel.org>,
        Viresh Kumar <viresh.kumar@...aro.org>
Cc:     Dominik Brodowski <linux@...inikbrodowski.net>,
        Linux PM <linux-pm@...r.kernel.org>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [RFC V2 1/6] cpufreq: Replace "max_transition_latency" with "dynamic_switching"

On Friday, July 14, 2017 01:11:58 PM Rafael J. Wysocki wrote:
> On Fri, Jul 14, 2017 at 9:01 AM, Dominik Brodowski
> <linux@...inikbrodowski.net> wrote:
> > On Thu, Jul 13, 2017 at 06:19:53PM +0200, Rafael J. Wysocki wrote:
> >> On Thu, Jul 13, 2017 at 7:40 AM, Viresh Kumar <viresh.kumar@...aro.org> wrote:
> >> > There is no limitation in the ondemand or conservative governors which
> >> > disallow the transition_latency to be greater than 10 ms.
> >> >
> >> > The max_transition_latency field is rather used to disallow automatic
> >> > dynamic frequency switching for platforms which didn't wanted these
> >> > governors to run.
> >> >
> >> > Replace max_transition_latency with a boolean (dynamic_switching) and
> >> > check for transition_latency == CPUFREQ_ETERNAL along with that. This
> >> > makes it pretty straight forward to read/understand now.
> >>
> >> Well, using CPUFREQ_ETERNAL for that on the driver side is still not
> >> particularly straightforward IMO, so maybe add a
> >> "no_dynamic_switching" to the driver structure and set it to "true"
> >> for the one driver in question?
> >
> > IIRC it's not just one driver which sets the latency to CPUFREQ_ETERNAL, and
> > where dynamic switching might be harmful or at least lead to undefined
> > behavior.
> 
> OK
> 
> Still, though, using CPUFREQ_ETERNAL to indicate the "no dynamic
> switching" condition is somewhat convoluted, so why don't we have a
> flag to *explicitly* say that instead?
> 
> Do you know which drivers they are or is it just all drivers that use
> CPUFREQ_ETERNAL?

Well, after the $subject patch it effectively is all drivers that use
CPUFREQ_ETERNAL anyway, so it looks like we actually can do a complete
switch-over.

Thanks,
Rafael