diff options
| author | Saravana Kannan <skannan@codeaurora.org> | 2017-10-12 15:56:12 -0700 |
|---|---|---|
| committer | Georg Veichtlbauer <georg@vware.at> | 2023-07-26 21:01:08 +0200 |
| commit | c0480aef1077795f97414ff7f73f32a4f8e682d8 (patch) | |
| tree | b325c0be8ec5e68a2d004db4092c40a8bc7049b7 /tools/perf/scripts/python/call-graph-from-postgresql.py | |
| parent | 2b573c8f032318907a8f1290350980ff0b61052e (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/call-graph-from-postgresql.py')
0 files changed, 0 insertions, 0 deletions
