summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/Perf-Trace-Util
diff options
context:
space:
mode:
authorViresh Kumar <viresh.kumar@linaro.org>2018-06-17 03:10:11 +0300
committerGeorg Veichtlbauer <georg@vware.at>2023-07-27 17:52:37 +0200
commit25c2cb9e8de74aa2460141542cdcb2fd03c94cba (patch)
tree76fea1c6d50fe9f8cfa9683e1fb146879a6d0a62 /tools/perf/scripts/python/Perf-Trace-Util
parent7c6d3914a32b1d536813dd95b1742eaa50065624 (diff)
cpufreq: schedutil: Don't set next_freq to UINT_MAX
The schedutil driver sets sg_policy->next_freq to UINT_MAX on certain occasions to discard the cached value of next freq: - In sugov_start(), when the schedutil governor is started for a group of CPUs. - And whenever we need to force a freq update before rate-limit duration, which happens when: - there is an update in cpufreq policy limits. - Or when the utilization of DL scheduling class increases. In return, get_next_freq() doesn't return a cached next_freq value but recalculates the next frequency instead. But having special meaning for a particular value of frequency makes the code less readable and error prone. We recently fixed a bug where the UINT_MAX value was considered as valid frequency in sugov_update_single(). All we need is a flag which can be used to discard the value of sg_policy->next_freq and we already have need_freq_update for that. Lets reuse it instead of setting next_freq to UINT_MAX. Change-Id: Ia37ef416d5ecac11fe0c6a2be7e21fdbca708a1a Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Joel Fernandes (Google) <joel@joelfernandes.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Yaroslav Furman <yaro330@gmail.com> - backported to 4.4
Diffstat (limited to 'tools/perf/scripts/python/Perf-Trace-Util')
0 files changed, 0 insertions, 0 deletions