Announcement

Collapse
No announcement yet.

Don't Look For Gentoo's CPU Optimization Options To Land In The Mainline Linux Kernel

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

  • #41
    Ingo is just butthurt he didn't come up with these patches

    Comment


    • #42
      Originally posted by starshipeleven View Post
      Quite frankly, this is not a kernel issue though. If you compile your own kernel with hardware-specific features and then you change hardware it's your own problem.
      In theory, yes, but I imagine it becomes their issue when they go into debugging stuff with a user and only later find out "oh, it uses --march=native". Whether this would happen is debatable, but what matters is their fear of it.

      Comment


      • #43
        Originally posted by GreenReaper View Post

        In theory, yes, but I imagine it becomes their issue when they go into debugging stuff with a user and only later find out "oh, it uses --march=native". Whether this would happen is debatable, but what matters is their fear of it.
        Oh my God. Who uses --march=native? Why? This is probably going to break your stuff when a new CPU comes out and you get it and it isn't backwards compatible. It definitely did when I moved from Bulldozer to Zen because Zen doesn't have FMA4 and other Bulldozer-specific instructions.

        Comment


        • #44
          In which case it is easy enough to compile for the new CPU in advance,or boot with a live CDand compile afterwards. Talk about a non issue.

          Comment


          • #45
            Originally posted by Spam View Post
            In which case it is easy enough to compile for the new CPU in advance,or boot with a live CDand compile afterwards. Talk about a non issue.
            I just explained how it can be an issue. If you're in my scenario, you can forget about booting and then chrooting to the old system. Not even bash will start if your binaries are incompatible with your CPU.

            Comment


            • #46
              Originally posted by rmoog View Post
              Oh my God. Who uses --march=native? Why? This is probably going to break your stuff when a new CPU comes out and you get it and it isn't backwards compatible. It definitely did when I moved from Bulldozer to Zen because Zen doesn't have FMA4 and other Bulldozer-specific instructions.
              Zen does execute FMA4 instructions fine, although it does not advertise them via /proc/cpuinfo flags. XOP however is unsupported.

              But it is enough to rebuild @system with generic CFLAGS before making the switch to a different CPU, and then rebuild @world with CPU-specific ones.

              Comment


              • #47
                This has been going on for ages and I used to do it myself in the Makefile/Kconfig.cpu, and while I didn't quantify it, I don't think it made any difference. Those benchmark results certainly don't change my mind.

                I remember a comment in the source, or Makefiles or somewhere: "Please note that patches adding -march=athlon-xp and friends are pointless at this time"

                I looked at this patch and as I thought, all it's doing is changing -march= for the various CPU types.

                If you look at the verbose compile command output (V=1) it's disabling advanced instructions anyway. -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx etc.

                That's just for the kernel code itself, not for the available instructions when it detects your CPU.

                P.S. I somehow posted in the wrong thread (meant to comment in the benchmark results thread), sorry for bumping this one.
                Last edited by Grogan; 02-27-2019, 04:42 PM.

                Comment


                • #48
                  Outside of Gentoo and other extreme-nerd-optimized deployment scenarios, the linux ecosystem is firmly entrenched around the assumption that kernels are binary blobs distributed by distribution vendors to customers.

                  Regarding these patches, I always have a vague fear that they will cause some sort of disconnect between the set of registers used by gcc's kernel text and the set of registers the kernel is designed to support during, i.e., context switching, kdbg, etc.... anyone know how realistic that fear is in practice?

                  Comment

                  Working...
                  X