Messages in this thread | | | From | "Rafael J. Wysocki" <> | Date | Sun, 2 Apr 2017 04:03:48 +0200 | Subject | Re: [RFC/RFT][PATCH] cpufreq: schedutil: Reduce frequencies slower |
| |
On Sun, Apr 2, 2017 at 1:29 AM, Andres Oportus <andresoportus@android.com> wrote: > On Sat, Apr 1, 2017 at 1:39 PM, Andres Oportus > <andresoportus@android.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.
>> 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.
Thanks, Rafael
| |