No announcement yet.

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

  • Filter
  • Time
  • Show
Clear All
new posts

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


    • #12
      Originally posted by Linuxxx View Post

      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.


      • #13
        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.


        • #14
          Originally posted by Linuxxx View Post

          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.





          Looking forward to skeevy's results.
          Last edited by reba; 11 October 2021, 03:23 PM.


          • #15
            Originally posted by Vistaus View Post

            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:

            [email protected]:/tmp# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
            conservative ondemand userspace powersave performance schedutil

            [email protected]:/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


            • #16
              [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]


              • #17
                Originally posted by [email protected] View Post

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

                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.


                • #18
                  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


                  • #19
                    Originally posted by perpetually high View Post

                    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.


                    • #20
                      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?