AMD Performance On Linux 5.11 Remains Mixed Due To Schedutil With Frequency Invariance

[phoronix]

Phoronix: AMD Performance On Linux 5.11 Remains Mixed Due To Schedutil With Frequency Invariance

Back on Christmas I wrote about Linux 5.11 regressing for AMD performance on Zen 2 and newer systems where the just-added CPU frequency invariance support was often hurting various workloads when using the default "Schedutil" scheduler utilization frequency scaling governor. Since then and through the holidays I have been carrying out many more benchmarks looking at the Linux 5.11 performance with a particular focus on the AMD desktop/server platforms.

http://www.phoronix.com/vr.php?view=29817

[ctlansdown]

Michael, I don't understand your lament that more distros don't default to the performance CPU governor. Doesn't it just statically set the CPU to maximum frequency, which significantly raises the power consumption? Not using power-saving features doesn't seem like an obviously good idea, that one would make that the default. What am I missing?

[aufkrawall]

Michael, I don't understand your lament that more distros don't default to the performance CPU governor. Doesn't it just statically set the CPU to maximum frequency, which significantly raises the power consumption?

No, because modern CPUs have shadow pstates in hardware and are not dependent on software governors to save a lot of power. With my 6700k, power consumption in total idle doesn't change at all with powersave vs. performance/no governor when measuring total system consumption via a wattmeter. Thus it is utter nonsense to use risk any performance penalty/stutter by using the likes of schedutil, ondemand or powersave governors with stationary systems. And even with my Gemini Lake mobile SoC the difference in power consumption is non-existent.

[intelfx]

No, because modern CPUs have shadow pstates in hardware and are not dependent on software governors to save a lot of power. With my 6700k, power consumption in total idle doesn't change at all with powersave vs. performance/no governor when measuring total system consumption via a wattmeter. Thus it is utter nonsense to use risk any performance penalty/stutter by using the likes of schedutil, ondemand or powersave governors with stationary systems. And even with my Gemini Lake mobile SoC the difference in power consumption is non-existent.

Your 6700k is using intel_pstate driver, which redefines both powerssve and performance governors. With this driver, P-states are controlled in hardware in both cases (thus HWP), while governor just sets aggressiveness of the decision algorithm (in rough terms).

In general case, for non-Intel CPUs, ctlansdown is correct.

[aufkrawall]

Your 6700k is using intel_pstate driver, which redefines both powerssve and performance governors. With this driver, P-states are controlled in hardware in both cases (thus HWP), while governor just sets aggressiveness of the decision algorithm (in rough terms).

I have both intel_pstate and acpi_cpufreq drivers blocked, thus cpupower reports no governor available and CPU package power is <10W in idle regardless.

In general case, for non-Intel CPUs, ctlansdown is correct.

Non-monolithic Ryzen CPUs eat a bit more power without OS governor, but still better than performance issues.

[Linuxxx]

aufkrawall
is correct - the performance governor, even the acpi_cpufreq one used by AMD systems, will not disable any power-saving features at all and will still successfully enter sleep states while being idle!
All that the performance governor ensures is that any given task will be completed as quickly as possible; so basically the optimal operation mode of "race-to-sleep|idle".

Anyone can easily verify this behaviour by executing:

sudo cpupower monitor

If your PC is doing nothing, you should be able to observe that the deepest sleep-state is being hit the majority of time - even with the acpi-cpufreq performance governor!

[shmerl]

So are Linux developers planning to fix schedutil to avoid this?

[jeisom]

aufkrawall
is correct - the performance governor, even the acpi_cpufreq one used by AMD systems, will not disable any power-saving features at all and will still successfully enter sleep states while being idle!
All that the performance governor ensures is that any given task will be completed as quickly as possible; so basically the optimal operation mode of "race-to-sleep|idle".

Anyone can easily verify this behaviour by executing:

sudo cpupower monitor

If your PC is doing nothing, you should be able to observe that the deepest sleep-state is being hit the majority of time - even with the acpi-cpufreq performance governor!

I just tested this on my 3800x and linux 5.10 and the temps went up about 9C while idling when switched to the performance governor. It might have gone up more, But I switched back after it got to 43. cpupower reported ~4GHz on all cores on performance as well idling.

[polarathene]

I have both intel_pstate and acpi_cpufreq drivers blocked, thus cpupower reports no governor available and CPU package power is <10W in idle regardless.

I could be wrong but if you're not using pstate as a governor, it still uses it internally for the HW? I think passive mode is the name, which allows alternative governors to influence somewhat if they like?

P-States are different from C-States though, which this discussion seems to be about regarding idle power usage vs frequency:

https://software.intel.com/content/www/us/en/develop/blogs/c-states-and-p-states-are-very-different.html

[intelfx]

I have both intel_pstate and acpi_cpufreq drivers blocked, thus cpupower reports no governor available and CPU package power is <10W in idle regardless.

Yes, because idle governors are orthogonal to frequency governors. Regardless of the cpufreq governor or driver you choose, your CPU will still enter idle states (C-states) when there is no work to do.

But when there _is_ work to do, cpufreq starts to matter, and the performance governor will force the CPU to highest frequency and thus your CPU will use considerably more power compared to a more conservative cpufreq governor.