Linus Torvalds Comes Out Against "Completely Broken" x86_64 Feature Levels

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
  • nadro
    Senior Member
    • Jan 2008
    • 304

    #21
    It's really funny that Linus have problem here, because it's just internal versioning for a set of features. If Linus has problems with simple versioning, why he use it for new kernel releases? He should release a long list of features, fixes etc. instead of some "stupid" numbers like 6.12.0 etc. Instead of "what the hell does 'v3' mean again?", we can say "what the hell does '6.12.0' mean again?".

    Comment

    • patrick1946
      Senior Member
      • Sep 2021
      • 356

      #22
      Originally posted by Gonk View Post
      No, any attempt to support AVX-512 was doomed before Alder Lake's e-cores came along.

      I'd love it if Zen 6 turned out to be a solid green row.
      Only AVX512F, AVX512BW, AVX512CD, AVX512DQ, AVX512VL is demanded by x86-64-v4. So even Skylake-SP is supported. But Alder lake is not.

      Comment

      • aerospace
        Phoronix Member
        • Apr 2024
        • 67

        #23
        Oh, if only he had more kernel developers! -.-'

        Comment

        • bkdwt
          Phoronix Member
          • May 2024
          • 79

          #24
          First: Linus, you need shut the hell up!
          Second: Where's the CoC to apply for you?

          Comment

          • schmidtbag
            Senior Member
            • Dec 2010
            • 6618

            #25
            Both Linus and the commenters here are pretty annoying about this.
            While I don't think it's really necessary to have feature levels like this, it's not really much of a problem either. All I care about is what instructions are supported, which as Linus pointed out, isn't consistent. All I want to know is what version of SSE and/or AVX are available. Summing it up as a version doesn't doesn't say that much.

            Comment

            • hardfalcon
              Junior Member
              • Mar 2019
              • 16

              #26
              Originally posted by carewolf View Post
              I mean by all means get rid of v4, it was always speculation, and reality has gone a different direction. But v2, and v3 are somewhat useful outside of the kernel.
              Even the usefulness of v2 and v3 seems questionable. One example: Even though Skylake CPUs are supposed to support AVX and AVX2, since last summer, the Linux kernel blocks/disables AVX and AVX2 support for userland code on Skylake CPUs to mitigate the GDS/Downfall vulnerability: https://www.phoronix.com/review/downfall

              Thankfully, at least Kaby Lake and later are not affected because Intel released a microcode fix for those, but Intel simply couldn't be bothered to release the same microcode fix for Skylake. This broke quite a bunch of userland software, including various Electron stuff such as element-desktop, and it took *months* to get the fixes for these bugs merged, even though in most cases, the root cause was simply Electron using outdated versions of dependecies that had already fixed their flawed AVX/AVX2 detection routines.

              Also, lets not forget how often Intel has disabled existing features in their CPUs through microcode updates in the past. The endless TSX odyssee is probably the most famous example, but another, more recent example is Intel disabling AVX-512 on Alder Lake through microcode updates.

              If distros were to use the x86_64v* approach to specify minimum system requirements and built their packages accordingly, the next SPECTRE mitigation could easily render entire CPU generations worth of real-world systems unbootable, instead of "just" breaking some Electron software.
              Last edited by hardfalcon; 05 December 2024, 10:25 AM.

              Comment

              • pokeballs
                Junior Member
                • Sep 2024
                • 37

                #27
                They are useful, but to be honest I don't really care about the "linear" part. What we need is just some generic-avx generic-avx2 etc levels

                Comment

                • bug77
                  Senior Member
                  • Dec 2009
                  • 6519

                  #28
                  Originally posted by spyke View Post
                  This model is used in many places, not only in glibc. For example, in Vulkan new extensions are added every week and then at some point in time a subset of new extensions is marked as mandatory and labelled as a new Vulkan version. So, instead of saying the kernel requires [a list of 354 x86 instuctions] you can simplify and say "our baseline is x86_v3".
                  The obvious difference being in the ISA world nothing is ever being marked as mandatory.
                  Linus is right, trying to represent something that is essentially non-linear as a linear v1, v2, etc. is a mental fallacy that is sure to cause more harm down the road.
                  Last edited by bug77; 05 December 2024, 11:32 AM.

                  Comment

                  • carewolf
                    Senior Member
                    • Nov 2012
                    • 2272

                    #29
                    Originally posted by pokeballs View Post
                    They are useful, but to be honest I don't really care about the "linear" part. What we need is just some generic-avx generic-avx2 etc levels
                    Well, for instance in a project I have worked it on means we can assume f16c is available in avx2 code, as we verify at runtime the whole v3 is available.

                    Of course this can break in all kinds of ways. Though the most recent one was with ARM. For instance we had to override armv9 for Apple to force armv8, because they implemented an only partial and broken SVE in the M4 processor, but claims it is Armv9, but for the similar levels in the arm world is that v9 includes SVE, and the SME instructions Apple do fully support _require_ SVE, hence the partial and broken implementation of SVE (just enough to get SME working, and they advertise v9 because the manuals says to check for v9 before checking for SME). But that is the problem with ARM they keep these versionssets in the cpuid, making it possible for manufactorers to lie.

                    Comment

                    • Errinwright
                      Senior Member
                      • Aug 2023
                      • 188

                      #30
                      Originally posted by Britoid View Post

                      CoC is only for people whom have different opinions.
                      Just a conduit of crazy

                      Comment

                      Working...
                      X