AMD Rembrandt CPUFreq vs. AMD P-State Linux Testing

[arQon]

AMD p-state wrecked the performance of my QEM-VFIO Windows VM, specially in cpu-limited games like MS Flight Simulator 2020. Had to revert back to acpi cpu_freq to get better performance. And both of them were running on the performance governor.

I remember Intel pstate being equally poor for several years, even without counting the now very well-known further problems that schedutil adds. Since AMD was "late" with their pstate support, and it's obviously a much harder problem than it appears from the outside, I think we can pretty much expect that it'll be another year or two at best before things really get resolved "well" with it.

As for schedutil, while it's nice to see it not being a massive regression in *every* test it's clearly still very badly broken for general use. IDK what the core problem with it is, but just flailing around at random like what's been happening for the last ?5? years now is obviously never going to arrive at being usable other than by luck.

It may be that schedutil is simply being driven by a different environment or set of goals (e.g. minimizing power costs at DCs rather than producing something suitable for desktops), but if not it's long since past time to step away from it and reconsider the basic logic, because it simply doesn't work well on any CPU, with any governor, and has shown very little indication that it ever will. :/

[microcode]

Eh, but task energy is actually *higher* for pstate schedutil in many benchmarks.


If idle power consumption is OK, it seems like pstate-performance is a saner default?

Ah, that isn't really addressed in the benchmarks. PTS really needs a "joules per iteration" or "iterations per kJ" or similar scale.

[Anux]

phoronix it's a very unfortunate choice to change the order of the items compared... switching from one plot to another it's not possible to follow the behavior from one test to another ... even more when there are closely related plots (the same test but various metrics like performance, freq, temp, power) the order should be kept fixed for all plots to allow the comparison for each item in the presented dimensions.

Yeah I also stumbled upon this. Maybe it would be a better solution to look at the final geomean and sort everything else acording to that.

What I hate about the results is how different options win at different applications, sometimes by a large margin. This means that to get the best performance it's necessary to try all the options per application.

Honestly there are only a few workloads that really need to be as fast as possible, for most other stuff modern CPUs are more than fast enough. Just look at your most demanding workload and do some tests, thats where you get the most benefits from optimizations. Maybe even recompile with native and Ofast.
Edit: For mobile devices its actually frustrating because you would always want the most power efficient solution.

[ET3D]

Thanks for all the testing, Michael. What I hate about the results is how different options win at different applications, sometimes by a large margin. This means that to get the best performance it's necessary to try all the options per application. I can't even be sure that it's per application, and that, for example, different Blender workloads won't respond differently.

[adriansev]

phoronix it's a very unfortunate choice to change the order of the items compared... switching from one plot to another it's not possible to follow the behavior from one test to another ... even more when there are closely related plots (the same test but various metrics like performance, freq, temp, power) the order should be kept fixed for all plots to allow the comparison for each item in the presented dimensions.

[shmerl]

Any news on these for desktop CPUs? Does this work for new Zen 4 ones?

[Random_Jerk]

AMD p-state wrecked the performance of my QEM-VFIO Windows VM, specially in cpu-limited games like MS Flight Simulator 2020. Had to revert back to acpi cpu_freq to get better performance. And both of them were running on the performance governor.

[BHZeto]

Hi,
I am playing with different powersave settings myself and was wondering if this can be measured with the Phoronix Test Suite using zenpower3 ...?

I installed the zenpower3-dkms package in Arch, and I guess that disables the k10temp module. Now when I run sensors command I can see the values for the CPU, and I can monitor the CPU temp with a KDE widget, but seems that I have lost the metrics on Phoronix side. Sadly it seems that I don't even have sys.power either.

[ptr1337]

@ptr1337 thanks, I thought it's already in kernel, this is too much work for me Gonna wait for it to be merged.
Did you noticed any difference compared to acpi-cpufreq powersave?

Its actually a upstream patch from lkml.
So far it does run really well.
I can't say you much, how it does run against acpi powersave, since did not used often powersave.

Actually, I have in my head how the amdpstate powersave does run, at this one runs very awful in my eyes.

It seems that the epp pstate runs differently, I use most time power preference. EPP seems to have a better PPW (powerperwatt) ratio and it does scale really well.
The performance from pstate epp power is actually equal to acpi performance / pstate performance.

Here you can find some more info's and some comparison:

https://lore.kernel.org/lkml/[email protected]/

[wooque]

@ptr1337 thanks, I thought it's already in kernel, this is too much work for me Gonna wait for it to be merged.
Did you noticed any difference compared to acpi-cpufreq powersave?