summaryrefslogtreecommitdiff
path: root/include/linux/tick.h
diff options
context:
space:
mode:
authorViresh Kumar <viresh.kumar@linaro.org>2017-02-21 10:15:18 +0530
committerRafael J. Wysocki <rafael.j.wysocki@intel.com>2017-03-12 23:11:33 +0100
commit994a8f2514e91c16616c4a1b53e9eb2b24de97b7 (patch)
tree3dec4ec470c6d1f5da72ff79e2a26dadc5ebb7ff /include/linux/tick.h
parent4495c08e84729385774601b5146d51d9e5849f81 (diff)
downloadlwn-994a8f2514e91c16616c4a1b53e9eb2b24de97b7.tar.gz
lwn-994a8f2514e91c16616c4a1b53e9eb2b24de97b7.zip
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 overhead comes from. The former is much less expensive in terms of execution time and running it every time the governor callback is invoked by the scheduler, after rate_limit_us interval has passed since the last frequency update, would not be a problem. For this reason, redefine the rate_limit_us tunable so that it means the minimum time that has to pass between two consecutive invocations of the scaling driver by the schedutil governor (to set the CPU frequency). Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Diffstat (limited to 'include/linux/tick.h')
0 files changed, 0 insertions, 0 deletions