Announcement

Collapse
No announcement yet.

Linux 5.11 Is Regressing Hard For AMD Performance With Schedutil

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

  • #11
    Cpufreq and governors has been in the making for.. a very long time.
    Schedutil, ondemand etc. All have had tons of caveats and whatnots of strange behavior.
    It has resulted in me just turning off cpufreq in my kernels or setting the governor to static performance for all cores.
    This has been my "default behavior" for almost a decade.
    I just don't trust this subsystem one iota.
    Last edited by milkylainen; 25 December 2020, 06:05 PM.

    Comment


    • #12
      Will someone please make a gofundme account so that we can fund AMD's Linux kernel support!!!

      It's 2020 people, wtf?! :-|

      Comment


      • #13
        Originally posted by milkylainen View Post
        ...setting the governor to static performance for all cores.
        This has been my "default behavior" for almost a decade...
        Even for boxes that mostly Idle i have a script to use performance when there is load.

        Comment


        • #14
          Some of the Linux 5.11 regressions are painful... (Don't worry, this CPU was already dead.)
          I wonder how this CPU could be killed before bending the pins.

          Comment


          • #15
            what does the kernel scheduler actually know about the code that's running on each core? or does it simply mean, that reclocking is synchronised with the dispatcher... assuming that data has arrived or some condition has been met?

            Comment


            • #16
              You are hero, Michael.

              Comment


              • #17
                Maybe the current schedutil implementation should be scrapped at this point. It's definitely a good idea to have some integration between process scheduling and cpu performance scaling, but benchmarks have shown again and again and again that the current implementation simply doesn't work.

                This really is a good example of sunken cost fallacy.

                Comment


                • #18
                  It seems that kernel development suffers in QA department (if there is any). Performance and reliability can be ruined at any time. Such problems can happen not only from unintended bugs but also from designed "improvements" which can have detrimental effects if they are not proven before commit with actual data and benchmarks.

                  Hardware companies should be doing the work Michael is doing.

                  BTW Michael, I remember you had found a nasty kernel regression on the transition from 4 to 5 and I didn't notice a follow-up on that.
                  Last edited by zoomblab; 26 December 2020, 06:22 AM.

                  Comment


                  • #19
                    Originally posted by zoomblab View Post
                    It seems that kernel development suffers in QA department (if there is any). Performance and reliability can be ruined at any time. Such problems can happen not only from unintended bugs but also from designed "improvements" which can have detrimental effects if they are not proven before commit with actual data and benchmarks.

                    Hardware companies should be doing the work Michael is doing.

                    BTW Michael, I remember you had found a nasty kernel regression on the transition from 4 to 5 and I didn't notice a follow-up on that.
                    I very agree with you!

                    Linux Fundation must become more pragmatic and reconsider their development strategy seriously.

                    Comment


                    • #20
                      Why don't switch directly to 5.12?

                      Comment

                      Working...
                      X