Ubuntu 19.10 To 21.10: AMD Zen 2 + Radeon Performance On Linux Over Two Years

[castlefox]

I wonder if there would be a similar performance increase with my Ryzen 1 CPU.

[skeevy420]

Since İ've been on the lookout for a newer generation CPU, İ've been wondering as well whether 'schedutil' is a better fit for these low base clocks & high boost clocks CPUs.
İf You could compare to the 'performance' governor, that would be great!
(Although results will probably change once the "AMD-PSTATE" CPU driver lands in mainline kernels.)

Right now I'm in the process of downloading all the tests used in the article and then I'm going to run them with ondemand, performance, and schedutil over the next couple of nights as I sleep on my R5 4650G system. I'm doing it that way since it took Michael ~7hrs per run with twice as many Zen 2 cores...though I have twice the memory, a crappier GPU, probably a slower SSD, Plasma on Xorg, Arch with a Zen2 pf kernel...totally an apples to apples comparison with Ubuntu 20.11.

I only have the one system so I have to use it by day and benchmark it by night. I really hope it doesn't scale into multiple 14 hour runs

Vistaus No idea. I don't run XanMod (but a quick glance at their patches didn't show anything that would remove it and their config shows it enabled). I use the Zen 2 build of linux-pf from this repository and it has schedutil.

[Vistaus]

skeevy420 That's odd, 'cause it does say

modprobe: FATAL: Module cpufreq_schedutil not found in directory /lib/modules/5.14.11-xanmod1-edge

and it doesn't show up in cpupower frequency-info either.

[reba]

Just curious:
Why 'ondemand' and not 'schedutil'?

İ believe part of the improvements we see in this round of benchmarking also have to do with the switch of the CPU governors.

İf You too could do a similar comparison by means of observation, that would be similarly great!

Here are some graphs.
One can see subtle, expected differences, especially between performance and powersave, however the used wattage, according to my wattmeter, are so close I cannot say I notice any meaningful difference. All were around 7,0 to 7,5 Watt for the full system with display, WiFi, Bluetooth, etc. on and Firefox and other stuff in the background with the system being idle otherwise.


ondemand:


performance:


powersave:


schedutil:


Looking forward to skeevy's results.

[reba]

Schedutil doesn't seem to be available on my system (Deepin 20). Is that because I'm running the XanMod kernel?

For me it's the other way around.

Standard Debian kernel has powersave, performance and ondemand, IIRC.

xanmod has:

root@debian:/tmp# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
conservative ondemand userspace powersave performance schedutil

root@debian:/tmp# uname -a
Linux debian 5.14.11-xanmod1-cacule #0~git20211009.664b18d SMP PREEMPT Sat Oct 9 17:44:28 UTC 2021 x86_64 GNU/Linux

[skeevy420]

[FONT=monospace][COLOR=#808080]╭─[/COLOR][COLOR=#b2b2b2][/COLOR][COLOR=#080808]  [/COLOR][COLOR=#b2b2b2][/COLOR][COLOR=#e4e4e4]   [/COLOR][COLOR=#eeeeee][B]~[/B][/COLOR][COLOR=#1818b2][/COLOR][COLOR=#808080]························[/COLOR][COLOR=#000000][/COLOR][COLOR=#18b218] ✔ [/COLOR][COLOR=#b2b2b2][/COLOR][COLOR=#000000] at 15:35:23   [/COLOR][COLOR=#b2b2b2][/COLOR]
[COLOR=#808080]╰─[/COLOR][COLOR=#000000] cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors [/COLOR]
conservative ondemand userspace powersave performance schedutil  

[COLOR=#808080]╭─[/COLOR][COLOR=#b2b2b2][/COLOR][COLOR=#080808]  [/COLOR][COLOR=#b2b2b2][/COLOR][COLOR=#e4e4e4]   [/COLOR][COLOR=#eeeeee][B]~[/B][/COLOR][COLOR=#1818b2][/COLOR][COLOR=#808080]························[/COLOR][COLOR=#000000][/COLOR][COLOR=#18b218] ✔ [/COLOR][COLOR=#b2b2b2][/COLOR][COLOR=#000000] at 15:36:24   [/COLOR][COLOR=#b2b2b2][/COLOR]
[COLOR=#808080]╰─[/COLOR][COLOR=#000000] uname -r [/COLOR]
5.14.11-xanmod1-cacule-1[/FONT]

[F.Ultra]

Reviewers discovered it first, but AMD had acknowledge the issue themselves:

https://www.amd.com/en/support/kb/faq/pa-400

Which is somewhat strange in this context since Linux does not even have preferred core scheduling in the first place so we should be equally struck bu this issue as W11. There are some external patches to add it but I don't think any of them have been mainlined.

[perpetually high]

Vistaus check which scaling governor you're using

You may be using (if I remember correctly) one of the Intel one's (intel_pstate or intel_cpufreq). Can play around with Intel_pstate=disable and intel_pstate=enable in your GRUB.

The scaling governor acpi-cpufreq should show all of them. Double check with phoronix-test-suite by Michael Larabel of Phoronix fame:

$ ./phoronix-test-suite system-info|head -n 15

PROCESSOR: Intel Core i5-4670K @ 4.30GHz
Core Count: 4
Extensions: SSE 4.2 + AVX2 + AVX + RDRAND + FSGSBASE
Cache Size: 6 MB
Microcode: 0x22
Core Family: Haswell
Scaling Driver: acpi-cpufreq performance (Boost: Enabled)

I also like the package cpufrequtils, which gives you cpufreq-info and cpufreq-set:

$ cpufreq-info|grep -E 'driver|governors'
driver: acpi-cpufreq
available cpufreq governors: conservative, ondemand, userspace, powersave, performance, schedutil

[skeevy420]

I also like the package cpufrequtils, which gives you cpufreq-info and cpufreq-set:

$ cpufreq-info|grep -E 'driver|governors'
driver: acpi-cpufreq
available cpufreq governors: conservative, ondemand, userspace, powersave, performance, schedutil

cpupower on Arch, etc. I wish package naming was a bit more consistent between distributions.

So, totally off topic but you'll get a kick, earlier tonight I ran

[FONT=monospace][COLOR=#000000]sudo mount -o remount,compress-force=zstd:15 /dev/sda2
sudo btrfs filesystem defragment -r -v /
sudo compsize -x /   [/COLOR]
Processed 750635 files, 890436 regular extents (896758 refs), 357244 inline.
Type       Perc     Disk Usage   Uncompressed Referenced   
TOTAL       66%       70G         106G         107G        
none       100%       42G          42G          43G        
zstd        44%       28G          64G          64G [/FONT]

and really wish I'd have thought about running compsize before doing that since I normally use compress-force=zstd:2

Unfortunately, I was more interested in if I could rather than the before and after.

[arQon]

How the hell is VP9 encoding THAT much slower than h265?! I thought I'd misread the labels at first, but nope: apparently it really is somwhere from 5x to 10x slower, to produce worse results.

I mean, sure, on the plus side at least it's not an MPEG standard with all the BS that entails (though VPx has basically no client HW support, whereas h265 has been ubiquitous for years) - but...

Am I missing something after all, and this isn't actually apples to apples? Or is the VP9 encoder really just catastrophically bad?