Announcement

Collapse
No announcement yet.

Linux 6.0 Merges The AMD Performance Fix For The Old "Dummy Wait" Workaround

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

  • #11
    Cool beans. I donated a fiver to Michael just to see what these metrics will look like against the Zen 4 numbers that went live today. I'm not expecting a cure for cancer here but I would think this chain and anchor finally being shed should increase the MPG a tad, so to speak. We got something to look forward to!

    Comment


    • #12
      Originally posted by ryao View Post
      I wonder if this helps the Steamdeck.
      Hmm...almost wondered if this fix would help FPS in games? MESA? Not a gamer myself but I am curious as to the scope, extent and benefit of it. We wait with bated breath.

      Comment


      • #13
        Also, how far back---in old kernel versions---can this be backported? I sat here thinking: If this issued had been found and addressed years ago, imagine how many hours of people's lives wouldn't have gone to waste? Seriously, if there's no impetus to hunt for or create tools to somehow find more of these oddball perf issues, I'd be kind of bummed out. Let the one-upmanship begin? I would love to see a bug bounty thing with this.
        Last edited by kozman; 26 September 2022, 09:54 PM.

        Comment


        • #14
          The Steamdeck uses a newer CPU that almost certainly does not have the need for this fix.

          But if it does need it, you can bet your ass Valve will make it a priority to get it patched ASAP.

          Comment


          • #15
            Originally posted by OmniNegro View Post
            The Steamdeck uses a newer CPU that almost certainly does not have the need for this fix.
            It effects newer CPUs. The whole issue is that there was a workaround for older Intel CPUs that was being errantly applied to newer AMD CPUs and slows down certain workloads on Ryzen, Epyc, and Threadripper significantly.

            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


            "Sampling certain workloads with IBS on AMD Zen3 system shows that a significant amount of time is spent in the dummy op, which incorrectly gets accounted as C-State residency. 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.

            One such workload is tbench where a massive performance degradation can be observed during certain runs.‚Äč"
            Last edited by Myownfriend; 26 September 2022, 10:52 PM.

            Comment


            • #16
              Originally posted by OmniNegro View Post
              The Steamdeck uses a newer CPU that almost certainly does not have the need for this fix.

              But if it does need it, you can bet your ass Valve will make it a priority to get it patched ASAP.
              First of all, you're wrong (and not for the first time either, mind you).

              Secondly, Valve still ships the Steam Deck with the schedutil CPU governor by default, which is very well known for causing stuttering & frame-time spikes.

              Therefore I don't see why they would be in any rush to address this particular issue here, either...

              [Valve-time, remember?]

              Comment


              • #17
                Originally posted by V1tol View Post
                My father still uses a notebook with Pentium M (comparable performance from the Athlon XP era) for OBD car diagnostics and it is a complete disaster under any distro that call itself lightweight. Antix, MXLinux, even Debian minimal install struggle just to decently run a desktop. Not saying about running that apps under Wine. And this notebook already has 3Gb of dual channel DDR2 and Intel SATA SSD.
                Same, but the issue with it is the video drivers. It's stuck using VESA mode, rather than native acceleration.

                Pentium M is probably close to a single core of a Raspberry Pi v4, when it's running AArch32 code.

                Originally posted by V1tol View Post
                Using 20+ y/o hardware as a server that can die at any moment? Unless you don't have anything else and you have free electricity.
                Yeah, any server too old to have PCIe and SATA isn't worth any time or effort. That heavily limits what kind of storage it can use, which probably means you're using old refurb drives at death's door. Core 2 Duo or AMD Phenom II are about the oldest things I'd even touch.

                P.S. the very first fileserver I built used a Pentium 4 with regular PCI SATA controller cards and I/O performance was unbelievably bad. When I upgraded to a Phenom II, the RAID sustained I/O was easily > 10x faster, for some inexplicable reason.
                Last edited by coder; 27 September 2022, 12:30 AM.

                Comment


                • #18
                  After this patch i have a lot of slowdowns on Yuzu that I didn't have before.

                  amd-pstate + schedutil + 5950x

                  Comment


                  • #19
                    Originally posted by HD7950 View Post
                    After this patch i have a lot of slowdowns on Yuzu that I didn't have before.

                    amd-pstate + schedutil + 5950x
                    This could mean Yuzu's dev was working around this somehow, even if they didn't know they were, and the fix broke that. It could also be Yuzu is sensitive to these types of changes, which is quite probable due to the nature of emulation.

                    Comment


                    • #20
                      Originally posted by anarki2 View Post
                      You have no idea what you're talking about. No, 20 years old PCs aren't "more than capable", they're pure garbage for any purpose.
                      My Duron 800 says you're wrong, while ripping 3 CDs with EAC over wine, checking them for correctnes, auto naming them and converting to flac.

                      If not for the performance, because, you like to do things in 5 minutes instead of 5 seconds for some reason, then for the ludicrous power drain compared to current systems. The things these pieces of junk can pull in 100W can be done with a 4W Raspberry pi now. Why would you do that, seriously.
                      Because old hardware is here and costs nothing while new stuff needs to be purchased.

                      And lightweight distros don't ship bleeding edge releases anyway, for that matter.
                      Arch Linux 32 is currently at 5.18 but will ship 6.0 if its ready.

                      Comment

                      Working...
                      X