profiles: Correct CPU governor settings #732
Conversation
marcan
force-pushed
the
fix-cpu-governors
branch
from
c6eff35 to
156d7a7
Compare
First, always prefer schedutil for balanced/powersave. On platforms where this governor is available, this enables Energy-Aware-Scheduling which offers the best power efficiency and performance combination. There is absolutely no reason to use another governor by default in the "balanced" profile on these systems, in particular. Second, swap around "conservative" and "ondemand". "conservative" is supposed to be lower power and higher latency. The commit that made this change [1] tested on a single server platform (10 years ago), but came to the wrong conclusion. Dividing the throughput by power numbers of that commit, "conservative" did in fact provide better performance/watt, which is the intent of lower-power modes. The fact that it also happened to provide better overall performance than "ondemand" is probably an artifact of suboptimal power-management behavior or a flawed test. [1] redhat-performance@b2897d9 Signed-off-by: Hector Martin <[email protected]>
marcan
force-pushed
the
fix-cpu-governors
branch
from
156d7a7 to
e24bfef
Compare
|
Come to think of it, the test used in that commit is just a very bad choice. It's some kind of DB performance test. Of course, when you use a test like that, you are mostly upclocking the CPU to max. With that kind of workload, the effect of "conservative" is reversed: it's also more conservative at throttling down so it would leave the CPUs at a high pstate longer, giving slightly better performance (and nearly no latency effect). The point of "conservative" is to not throttle up for spiky workloads (desktop use cases), giving significantly worse latency instead, but better pure-CPU perf/W. The test used does not measure that. And the reason why perf/W is better the faster it goes is because that server probably has a ridiculous baseline idle power consumption, so "race-to-idle" wins and the more CPU you can burn per time, the better. Which just means that particular server platform should probably just be using "performance" all the time because it has terrible PM and that choice gives the best performance and perf/W, making tuned's balanced/powersave profiles pointless on it unless you want to just get less work done using more energy. |
|
Reports of user regressions from tuned without this change: https://mastodon.social/@fosstastic/113865820277772906 |
|
Thanks, LGTM. I guess you target tuned-2.25.0 stable? |
Yes. We'd like to see this shipped in Fedora 41+. |
|
OK, NP. Also Fedora doesn't need to wait for upstream releases which happen in cca. 6 month intervals, we can backport important patches into Fedora, once merged or approved upstream. |
|
Awesome, thanks. Will this also make it into RHEL 10? |
Yes, it should. |
First, always prefer schedutil for balanced/powersave. On platforms where this governor is available, this enables Energy-Aware-Scheduling which offers the best power efficiency and performance combination. There is absolutely no reason to use another governor by default in the "balanced" profile on these systems, in particular.
Second, swap around "conservative" and "ondemand". "conservative" is supposed to be lower power and higher latency. The commit that made this change [1] tested on a single server platform (10 years ago), but came to the wrong conclusion. Dividing the throughput by power numbers of that commit, "conservative" did in fact provide better performance/watt, which is the intent of lower-power modes. The fact that it also happened to provide better overall performance than "ondemand" is probably an artifact of suboptimal power-management behavior or a flawed test. In fact, "performance" gave even better perf/W in that test, which is just absurd and shows that platform was not at all representative of the effect changing CPU frequency governors is supposed to have on a well-behaved platform.
[1] b2897d9
Bugs: