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] [day] [month] [year] [list]
Date:   Sat, 1 Apr 2017 21:38:12 -0700
From:   Andres Oportus <>
To:     "Rafael J. Wysocki" <>
Cc:     Juri Lelli <>,
        Linux PM <>,
        LKML <>,
        Peter Zijlstra <>,
        Srinivas Pandruvada <>,
        Viresh Kumar <>,
        Vincent Guittot <>,
        Patrick Bellasi <>,
        Joel Fernandes <>,
        Morten Rasmussen <>,
        John <>
Subject: Re: [RFC/RFT][PATCH] cpufreq: schedutil: Reduce frequencies slower

On Sat, Apr 1, 2017 at 7:03 PM, Rafael J. Wysocki <> wrote:
> On Sun, Apr 2, 2017 at 1:29 AM, Andres Oportus
> <> wrote:
>> On Sat, Apr 1, 2017 at 1:39 PM, Andres Oportus
>> <> wrote:
>>> Hi Rafael, Juri,
> [cut]
>>>> > As we discussed at the last LPC, having an energy model handy and use
>>>> > that to decide how quickly to ramp up or slow down seems the desirable
>>>> > long term solution, but we probably need something (as you are
>>>> > proposing) until we get there.
>>>> Well, we definitely need something to address real use cases, like the one
>>>> that
>>>> I responded to with this patch. :-)
>>> I don't know the history/intent behind schedutil rate limiting, but if we
> Basically, the hardware cannot be requested to change the frequency
> too often as that would be too expensive in general.
Expensiveness of changing the frequency too often is one of the
reasons we need to have down throttle in Android, but we can't have
this value also slow down the frequency increases (so up throttle
being equal to down throttle is bad for us) which would affect

>>> make it to be only "down" as Juri mentioned we would not be adding a new
>>> tunable but rather changing the current one to be more restricted (maybe
>>> some renaming would be in order if this is done), this would provide
>>> hysteresis to reduce this problem without locking the amount of the
>>> hysteresis which may not work for all platforms.  I also agree that "it is
>>> difficult to imagine that the same values will always be suitable for every
>>> workload", but without any value to control the whole system, we get nothing
>>> in between.  Ultimately I also think we should solve the hysteresis problem
>>> at the root, i.e. the input to the governor in the form of util/load that
>>> has not only hysteresis and energy model, but also any other behavioral
>>> inputs built-in.
> That's long-term, though, and besides knobs only help if users change
> the defaults.  From my experience they usually don't do that.
Agreed that it is long term.  Regarding knobs, we are already tuning
the down throttle value for Android (we currently do 50ms down for the
similar knob in schedfreq).

> Thanks,
> Rafael


Powered by blists - more mailing lists