Re: [PATCH V2] cpufreq: schedutil: Redefine the rate_limit_us tunable

On 24-02-17, 00:36, Rafael J. Wysocki wrote: > I'd prefer this to spend some time in linux-next before it goes into > the mainline, so I will queue it up for 4.12 if no one objects by the > end of the next week. Sure. Thanks. -- viresh

Re: [PATCH V2] cpufreq: schedutil: Redefine the rate_limit_us tunable

On 24-02-17, 00:36, Rafael J. Wysocki wrote: > I'd prefer this to spend some time in linux-next before it goes into > the mainline, so I will queue it up for 4.12 if no one objects by the > end of the next week. Sure. Thanks. -- viresh

Re: [PATCH V2] cpufreq: schedutil: Redefine the rate_limit_us tunable

On Tue, Feb 21, 2017 at 5:45 AM, Viresh Kumar wrote: > The rate_limit_us tunable is intended to reduce the possible overhead > from running the schedutil governor. However, that overhead can be > divided into two separate parts: the governor computations and the >

Re: [PATCH V2] cpufreq: schedutil: Redefine the rate_limit_us tunable

On Tue, Feb 21, 2017 at 5:45 AM, Viresh Kumar wrote: > The rate_limit_us tunable is intended to reduce the possible overhead > from running the schedutil governor. However, that overhead can be > divided into two separate parts: the governor computations and the > invocation of the scaling

[PATCH V2] cpufreq: schedutil: Redefine the rate_limit_us tunable

The rate_limit_us tunable is intended to reduce the possible overhead from running the schedutil governor. However, that overhead can be divided into two separate parts: the governor computations and the invocation of the scaling driver to set the CPU frequency. The latter is where the real

[PATCH V2] cpufreq: schedutil: Redefine the rate_limit_us tunable

The rate_limit_us tunable is intended to reduce the possible overhead from running the schedutil governor. However, that overhead can be divided into two separate parts: the governor computations and the invocation of the scaling driver to set the CPU frequency. The latter is where the real