On Sun, Apr 2, 2017 at 1:29 AM, Andres Oportus <[email protected]> wrote: > On Sat, Apr 1, 2017 at 1:39 PM, Andres Oportus > <[email protected]> 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
