linux-kernel - Re: [RFC/RFT][PATCH] cpufreq: schedutil: Reduce frequencies slower

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]

Message-ID: <CAFEhuF=n9+LkQoMVLsNCo9peLNUo5XRBX8NTmcsuuJwYJwUtGw@mail.gmail.com>
Date:   Sat, 1 Apr 2017 21:38:12 -0700
From:   Andres Oportus <andresoportus@...roid.com>
To:     "Rafael J. Wysocki" <rafael@...nel.org>
Cc:     Juri Lelli <juri.lelli@....com>,
        Linux PM <linux-pm@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>,
        Viresh Kumar <viresh.kumar@...aro.org>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Patrick Bellasi <patrick.bellasi@....com>,
        Joel Fernandes <joelaf@...gle.com>,
        Morten Rasmussen <morten.rasmussen@....com>,
        John <john.ettedgui@...il.com>
Subject: Re: [RFC/RFT][PATCH] cpufreq: schedutil: Reduce frequencies slower

On Sat, Apr 1, 2017 at 7:03 PM, Rafael J. Wysocki <rafael@...nel.org> wrote:
> On Sun, Apr 2, 2017 at 1:29 AM, Andres Oportus
> <andresoportus@...roid.com> wrote:
>> On Sat, Apr 1, 2017 at 1:39 PM, Andres Oportus
>> <andresoportus@...roid.com> 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
interactivity/response-time.

>
>>> 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

Thanks,
Andres