summaryrefslogtreecommitdiff
path: root/drivers/cpufreq
diff options
context:
space:
mode:
authorSteve Muckle <steve.muckle@linaro.org>2016-07-13 20:25:26 (GMT)
committerRafael J. Wysocki <rafael.j.wysocki@intel.com>2016-07-21 20:28:21 (GMT)
commit5cbea46984d67f614c74c4401b54b9d681861e80 (patch)
tree8976fba256b849b38def373e02f5570bfe074dd1 /drivers/cpufreq
parente3c06236087051d5c62d60d0668588c370fda887 (diff)
downloadlinux-5cbea46984d67f614c74c4401b54b9d681861e80.tar.xz
cpufreq: schedutil: map raw required frequency to driver frequency
The slow-path frequency transition path is relatively expensive as it requires waking up a thread to do work. Should support be added for remote CPU cpufreq updates that is also expensive since it requires an IPI. These activities should be avoided if they are not necessary. To that end, calculate the actual driver-supported frequency required by the new utilization value in schedutil by using the recently added cpufreq_driver_resolve_freq API. If it is the same as the previously requested driver frequency then there is no need to continue with the update assuming the cpu frequency limits have not changed. This will have additional benefits should the semantics of the rate limit be changed to apply solely to frequency transitions rather than to frequency calculations in schedutil. The last raw required frequency is cached. This allows the driver frequency lookup to be skipped in the event that the new raw required frequency matches the last one, assuming a frequency update has not been forced due to limits changing (indicated by a next_freq value of UINT_MAX, see sugov_should_update_freq). Signed-off-by: Steve Muckle <smuckle@linaro.org> Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Diffstat (limited to 'drivers/cpufreq')
0 files changed, 0 insertions, 0 deletions