On Fri, 21 Nov 2025 at 04:55, Sergey Senozhatsky senozhatsky@chromium.org wrote:
Hi Christian,
On (25/11/20 10:15), Christian Loehle wrote:
On 11/20/25 04:45, Sergey Senozhatsky wrote:
Hi,
We are observing a performance regression on one of our arm64 boards. We tracked it down to the linux-6.6.y commit ada8d7fa0ad4 ("sched/cpufreq:
You mentioned that you tracked down to linux-6.6.y but which kernel are you using ?
Rework schedutil governor performance estimation").
UI speedometer benchmark: w/commit: 395 +/-38 w/o commit: 439 +/-14
Hi Sergey, Would be nice to get some details. What board?
It's an MT8196 chromebook.
What do the OPPs look like?
How do I find that out?
In /sys/kernel/debug/opp/cpu*/ or /sys/devices/system/cpu/cpufreq/policy*/scaling_available_frequencies with related_cpus
Does this system use uclamp during the benchmark? How?
How do I find that out?
it can be set per cgroup /sys/fs/cgroup/system.slice/<name>/cpu.uclam.min|max or per task with sched_setattr()
You most probably use it because it's the main reason for ada8d7fa0ad4 to remove wrong overestimate of OPP
Given how large the stddev given by speedometer (version 3?) itself is, can we get the stats of a few runs?
v2.1
w/o patch w/ patch 440 +/-30 406 +/-11 440 +/-14 413 +/-16 444 +/-12 403 +/-14 442 +/-12 412 +/-15
Maybe traces of cpu_frequency for both w/ and w/o?
trace-cmd record -e power:cpu_frequency attached.
"base" is with ada8d7fa0ad4 "revert" is ada8d7fa0ad4 reverted.