summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python
diff options
context:
space:
mode:
authorSaravana Kannan <skannan@codeaurora.org>2017-10-12 15:56:12 -0700
committerGeorg Veichtlbauer <georg@vware.at>2023-07-26 21:01:08 +0200
commitc0480aef1077795f97414ff7f73f32a4f8e682d8 (patch)
treeb325c0be8ec5e68a2d004db4092c40a8bc7049b7 /tools/perf/scripts/python
parent2b573c8f032318907a8f1290350980ff0b61052e (diff)
cpufreq: schedutil: Use >= when aggregating CPU loads in a policy
When the normal utilization value for all the CPUs in a policy is 0, the current aggregation scheme of using a > check will result in the aggregated utilization being 0 and the max value being 1. This is not a problem for upstream code. However, since we also use other statistics provided by WALT to update the aggregated utilization value across all CPUs in a policy, we can end up with a non-zero aggregated utilization while the max remains as 1. Then when get_next_freq() tries to compute the frequency using: max-frequency * 1.25 * (util / max) it ends up with a frequency that is greater than max-frequency. So the policy frequency jumps to max-frequency. By changing the aggregation check to >=, we make sure that the max value is updated with something reported by the scheduler for a CPU in that policy. With the correct max, we can continue using the WALT specific statistics without spurious jumps to max-frequency. Change-Id: I14996cd796191192ea112f949dc42450782105f7 Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
Diffstat (limited to 'tools/perf/scripts/python')
0 files changed, 0 insertions, 0 deletions