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

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

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

    This morning I called attention to some pending work around a 20 year old chipset workaround in the Linux kernel had been hurting modern AMD systems by erroneously still applying the change to modern hardware. Fortunately, that patch has now been picked up by Linus Torvalds in time for the Linux 6.0 kernel expected for its stable debut next weekend...

    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
    Wait, what about the old AMD systems with VIA chipsets that were supposedly affected?

    Comment


    • #3
      Originally posted by andrebrait View Post
      Wait, what about the old AMD systems with VIA chipsets that were supposedly affected?
      I guess they won't idle with modern kernels. They won't have proper video drivers with recent distros either, and are unlikely to support enough RAM to tolerate recent distros, so in all the problematic planned obsolescence in all that scenario, I think this patch is the least of your worries. For these chipsets you'll probably just stick to an older distro with an older kernel.

      EDIT: besides, if you read the patch it says the motivating chipset was assumed to be an Intel one, and the patch just checks the chip is Intel before applying the workaround. It also points out that modern Intel chips use a different function. So, essentially, this is inconsequential to those chipsets.

      Comment


      • #4
        Originally posted by sinepgib View Post

        I guess they won't idle with modern kernels. They won't have proper video drivers with recent distros either, and are unlikely to support enough RAM to tolerate recent distros, so in all the problematic planned obsolescence in all that scenario, I think this patch is the least of your worries. For these chipsets you'll probably just stick to an older distro with an older kernel.

        EDIT: besides, if you read the patch it says the motivating chipset was assumed to be an Intel one, and the patch just checks the chip is Intel before applying the workaround. It also points out that modern Intel chips use a different function. So, essentially, this is inconsequential to those chipsets.
        I'd think plenty of modern distros do still support them. 2002 was a while ago, sure, but there gotta be a ton of late K7 / early K8 CPUs out there on mobos with VIA chipsets that would still benefit from running supported (therefore relatively recent) distros with recent kernel versions.

        The Athlon 64 was released in 2003. Athlon XP systems are more than capable of running modern lightweight distros. 1GB of RAM is plenty for them.

        And having good support for video acceleration and plenty of RAM is irrelevant here. Not every computer even runs a GUI. And even then, XFCE, LXDE and other minimalist DEs are out there.

        The original article said some of those were affected by this workaround too, as they suffer from whatever bug that's working around, so just checking if it's an Intel CPU or not wouldn't suffice in this case.

        I mean, I probably know less than the author of the patch, but even knowledgeable people fuck up sometimes.

        Comment


        • #5
          I wonder if this helps the Steamdeck.

          Comment


          • #6
            Originally posted by andrebrait View Post

            I'd think plenty of modern distros do still support them. 2002 was a while ago, sure, but there gotta be a ton of late K7 / early K8 CPUs out there on mobos with VIA chipsets that would still benefit from running supported (therefore relatively recent) distros with recent kernel versions.

            The Athlon 64 was released in 2003. Athlon XP systems are more than capable of running modern lightweight distros. 1GB of RAM is plenty for them.

            And having good support for video acceleration and plenty of RAM is irrelevant here. Not every computer even runs a GUI. And even then, XFCE, LXDE and other minimalist DEs are out there.

            The original article said some of those were affected by this workaround too, as they suffer from whatever bug that's working around, so just checking if it's an Intel CPU or not wouldn't suffice in this case.

            I mean, I probably know less than the author of the patch, but even knowledgeable people fuck up sometimes.
            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.

            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.

            And lightweight distros don't ship bleeding edge releases anyway, for that matter.

            If huge masses of people are still on 20 years old PCs, and all of them wanna run Linux 6.0 because reasons, and this code indeed breaks some things for them, then they will let the kernel developers know, you don't have to worry for them in advance.

            You might also stop for a moment and think about your priorities. Should we focus on current PCs when we develop our current kernel, or junk from 20 years ago? Hmmm... Tough one indeed.

            Comment


            • #7
              Originally posted by andrebrait View Post
              2002 was a while ago
              It was 20 years ago lol.
              Originally posted by andrebrait View Post
              late K7 / early K8
              You are basically mixing unmixable. K7 are 32 bit CPUs even without SSE2 support, K8 are 64 bit CPUs. That's an extreme difference in terms of performance and distro support.
              Originally posted by andrebrait View Post
              Athlon XP systems are more than capable of running modern lightweight distros. 1GB of RAM is plenty for them.
              That's not true. I had multiple Athlon XPs in past - sold them as soon as I got my hands on 64-bit first on socket 754 then on 939. 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. Eventually I just installed Windows 7 there because every time I tried to do minimal modern (not a 15 y/o distro) Linux install it turned out to be a complete waste of time. My experience shows that "outdated" for Linux nowadays means 2 cores 64 bit as a bare minimum to run desktop with browser at least bearable.
              Originally posted by andrebrait View Post
              Not every computer even runs a GUI
              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.

              Comment


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

                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.

                And lightweight distros don't ship bleeding edge releases anyway, for that matter.

                If huge masses of people are still on 20 years old PCs, and all of them wanna run Linux 6.0 because reasons, and this code indeed breaks some things for them, then they will let the kernel developers know, you don't have to worry for them in advance.

                You might also stop for a moment and think about your priorities. Should we focus on current PCs when we develop our current kernel, or junk from 20 years ago? Hmmm... Tough one indeed.
                I have no idea what I'm talking about? That's a bold claim.

                You forget 3rd world countries exist, I see?

                Speaking as someone who lived in one for 30 years, yes, some people are still rocking 2002 era hardware. Athlon XPs or Durons aren't that uncommon. Heck, even K6-IIs and Pentium II/III/Celerons aren't that hard to find, still working.

                Yeah, they're slow as fuck and take upwards of a minute to open a web page, but that doesn't mean *no one* is using them and most certainly it doesn't mean they're useless.

                So what if a Raspberry Pi can outperform them? The best computer is the one you already have and can afford. A Raspberry Pi 4B starter kit costs over half a monthly minimum wage over there, after taxes (which are high as hell).

                And no one here said anything about preventing progress of modern computers. What I questioned would be an additional if statement, at most.

                Comment


                • #9
                  Originally posted by V1tol View Post
                  It was 20 years ago lol.

                  You are basically mixing unmixable. K7 are 32 bit CPUs even without SSE2 support, K8 are 64 bit CPUs. That's an extreme difference in terms of performance and distro support.

                  That's not true. I had multiple Athlon XPs in past - sold them as soon as I got my hands on 64-bit first on socket 754 then on 939. 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. Eventually I just installed Windows 7 there because every time I tried to do minimal modern (not a 15 y/o distro) Linux install it turned out to be a complete waste of time. My experience shows that "outdated" for Linux nowadays means 2 cores 64 bit as a bare minimum to run desktop with browser at least bearable.

                  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.
                  I'm not mixing anything. 2002 was when some late K7 were launched and 2003 was when the first K8 were launched. I just meant to say you shouldn't dismiss hardware just because of age. Not sure why you brought up bits and performance, specially when the initial K8 CPUs were just ~15% faster than the Athlon XPs they replaced. Being 64-bit just gets you some extra software support, but there are distros that still ship i686 ISOs so I literally have no idea what you're onto here. i686 images aren't usually compiled in a way that requires SSE2 anyway.

                  I'm not saying these computers are great, but they're not useless. And I have installed relatively new (at the time) Linux distros on Athlon XPs and not-that-newer hardware just 5 or 6 years ago. I still have a socket 754 Sempron (yes, K8, I know) running at a friend's at the moment, no issues whatsoever. Slow? Sure. Usable? Totally.

                  Also, I never said anything about servers. I'd agree those computers that run GUI-less for other purposes usually don't get upgraded anyway, but that's besides the point. When they do, it'd be nice if things kept working.

                  Comment


                  • #10
                    The real question is: Who has an affected system and is able to test and profile this?

                    Comment

                    Working...
                    X