Announcement

Collapse
No announcement yet.

A 20 Year Old Chipset Workaround Has Been Hurting Modern AMD Linux Systems

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

  • #11
    Originally posted by obri View Post
    I hope we will see some performace tests with and without that optimization?
    It does sound like it could help some I/O-heavy workloads or perhaps some multithreaded benchmarks with lots of lock or resource contention. It's got to be something where you have cores frequently going in & out of IDLE.

    "A large C-State residency value can prime the cpuidle governor to recommend a deeper C-State during the subsequent idle instances, starting a vicious cycle, leading to performance degradation on workloads that rapidly switch between busy and idle phases."

    Comment


    • #12
      Now Phoronix needs to publish new benchmarks with and without the patch, so we can see how cooler our AMD boxes really are.

      Comment


      • #13
        Originally posted by gigaplex View Post

        If they knew about the issue they would have fixed it.
        It seems Linux competition is so slow AMD didn't even notice such suboptimal performance.

        Comment


        • #14
          Originally posted by milkylainen View Post

          I think it mostly tells us that the kernel is filled to the brim with old cruft and we can't keep track of everything.
          Over time, information gets lost.
          All it really needed was somebody to look close enough into that dark, funky smelling, corner. :P
          And it took roughly 20 years before someone with an AMD CPU actually used a profiler and re-discovered this performance-costing code path. And no one else either seemed to have taken notice that or bothered to fix it before, that's the scary part. I'd assume if you deploy thousands or millions of these in your farm and you'd want to squeeze out everything you can from your investment to get a competitive advantage, they pay programmers for that sort of thing (which involves using profilers and inspection of vendor specific code paths in old code bases).
          Last edited by ms178; 26 September 2022, 10:07 AM.

          Comment


          • #15
            Originally posted by ms178 View Post

            And it took roughly 20 years before someone with an AMD CPU actually used a profiler and re-discovered this performance-costing code path. And no one else either seemed to have taken notice that or bothered to fix it before, that's the scary part. I'd assume if you deploy thousands or millions of these in your farm you'd want to squeeze out everything you can from your investment to get a competitive advantage and that they pay programmers for that sort of thing.
            To be fair, the average software developer profiling Linux would probably miss this since profiling typically measures when the CPU is doing something, not when the CPU is idle.

            Comment


            • #16
              Thanks for listing these headlines all in one post, but as a long-term viewer of this site, I've been aware of this development. After their newfound fortune they were still a bit late with their Linux-dedicated hiring spree in my eyes. Also I haven't seen that many upstream committs in LLVM/GCC/glibc for the AMD CPU side during the last couple of years still. There are occasional contributions from them to these projects but they are not actively driving them forward. If they want to become the dominant x86-player in the market, their software engagement needs to grow even further.

              Comment


              • #17
                Originally posted by ryao View Post

                To be fair, the average software developer profiling Linux would probably miss this since profiling typically measures when the CPU is doing something, not when the CPU is idle.
                Yeah, you would need to run a kernel profiler, and who does that?

                Comment


                • #18
                  Wow. This isn't even low hanging fruit. It may have once been but it's been rotting on the floor for over a decade. It makes one wonder how many other small wins like this are lurking about in the kernel code? Surely this isn't an isolated incident?

                  Comment


                  • #19
                    I wonder how many such workarounds/quirks are in the Windows source code where hardware vendors have no or little insight. Lol.

                    Comment


                    • #20
                      Originally posted by ryao View Post

                      To be fair, the average software developer profiling Linux would probably miss this since profiling typically measures when the CPU is doing something, not when the CPU is idle.
                      reminded of my 3800XT which was consistently flawless under load, but would periodically blue-screen under idle conditions.

                      took some work to persuade the vendor to RMA it (and test it properly to confirm the problem!).

                      Comment

                      Working...
                      X