Announcement

Collapse
No announcement yet.

AMD Ryzen 9 3900XT CPUFreq Governor Comparison With Linux 5.9

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • AMD Ryzen 9 3900XT CPUFreq Governor Comparison With Linux 5.9

    Phoronix: AMD Ryzen 9 3900XT CPUFreq Governor Comparison With Linux 5.9

    One of the most frequent questions received at Phoronix in recent times is whether the "schedutil" governor is ready for widespread use and if it can compare in performance to, well, the "performance" governor on AMD Linux systems. Here are some benchmarks of an AMD Ryzen 9 3900XT using the latest Linux 5.9 development kernel in looking at the performance differences between the CPUFreq governor options of Ondemand, Powersave, Performance, and Schedutil.

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    The schedutil governor remains a disappointment. With ondemand on its default settings still performing better is there no need for schedutil on AMD.

    The ondemand governor also features tunable parameters that allow it to be tweaked while still providing power savings when machines are idle. For example...
    Code:
    echo 50 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold
    echo 10 > /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor
    Here "50" means to switch up the frequency at 50% load, and the "10" means to keep the frequency high for 10 times longer, thus processes run more often and longer at a high frequency.

    Maybe it is time to add some more tunable parameters to schedutil, because at least on AMD is schedutil far from being better nor a replacement of the older ondemand governor as the documentation wants to have us know.

    Comment


    • #3
      IDK, do people and the author even understand that: "When CPU frequency governor is set to "powersave" mode, CPU is set to the lowest static frequency (within the borders of scaling_min_freq and scaling_max_freq)." ? What is even the point to include a "static minimal frequency" run, ..?

      Comment


      • #4
        Is the ondemand scheduler broken or AMD CPUs are broken under Linux? This scheduler is used by default in absolute most Linux distros. Damn.

        It should have the results which are similar to the performance scheduler yet in many cases it's 33% slower.

        Comment


        • #5
          Expecting the best performance in a rapid-turbo boost situation to be gained with the performance governor is nothing to be surprised by. How many of these workloads actually take a long to time to complete under load where the other governors are actually causing problems? A microbenchmark that is done before the CPU has changed C-states isn't going to make a big difference in real world performance.

          Comment


          • #6
            Looking forward to the mobile test where performance is more thermal limited.

            Comment


            • #7
              Originally posted by sdack View Post
              The schedutil governor remains a disappointment. With ondemand on its default settings still performing better is there no need for schedutil on AMD.

              Maybe it is time to add some more tunable parameters to schedutil, because at least on AMD is schedutil far from being better nor a replacement of the older ondemand governor as the documentation wants to have us know.
              The article actually doesn't really suggest that, and for distributions such as Arch, it seems to me that it's not worth enabling and switching to ondemand one, schedutil seems to do the job quite well and comparably to the ondemand.

              Comment


              • #8
                The results are odd to say the least. First of all, the differences between full on maximum power draw vs on-demand are too big. If you get some sort of lower single digit performance difference on Windows with the "Ryzen Power Plan" vs "Fire everything", its already considered "too much of a gap" by gamers and they start to complain, so it has been tuned to a point where both are the same (esp. with community tools like 1usmus custom Ryzen Power Plan)

                Looking at the results, anything aside max power draw is a dissapointment. Esp. Schedutil which should be somewhere between on-demand and max power draw. My impression: Schedutil is kind of optimized for Intel and can't take advantage of the under-the-hood params on Zen 2 CPUs, doing SNAFU. At least I now know which setting I should take.

                Comment


                • #9
                  Typo:

                  Originally posted by phoronix View Post
                  has already appeared in some scenarions as the default on recent kernel versions.

                  Comment


                  • #10
                    Originally posted by sdack View Post
                    The schedutil governor remains a disappointment. With ondemand on its default settings still performing better is there no need for schedutil on AMD.

                    The ondemand governor also features tunable parameters that allow it to be tweaked while still providing power savings when machines are idle. For example...
                    Code:
                    echo 50 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold
                    echo 10 > /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor
                    Here "50" means to switch up the frequency at 50% load, and the "10" means to keep the frequency high for 10 times longer, thus processes run more often and longer at a high frequency.

                    Maybe it is time to add some more tunable parameters to schedutil, because at least on AMD is schedutil far from being better nor a replacement of the older ondemand governor as the documentation wants to have us know.
                    You can also use schedutil with:
                    Code:
                    echo 0 >> /sys/devices/system/cpu/cpufreq/schedutil/rate_limit_us
                    For me it's at least onpar with ondemand with this setting on a 3970X.

                    Comment

                    Working...
                    X