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
    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


    • #42
      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


      • #43
        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


        • #44
          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


          • #45
            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


            • #46
              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; 27 February 2019, 04:42 PM.

              Comment


              • #47
                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


                • #48
                  Very old thread, but one thing thats very misleading in the open-source community is that their's very little open mindedness in it.
                  I agree with the Kernel maintainers that there is risk involved and they shouldnt merge anything that theyre not comfortable with, but ideas need to be supported and *valued* first and foremost. Without new ideas youre just gonna have a project with people who never come up with anything.

                  Comment


                  • #49
                    Originally posted by AdamOne View Post
                    Very old thread, but one thing thats very misleading in the open-source community is that their's very little open mindedness in it.
                    I agree with the Kernel maintainers that there is risk involved and they shouldnt merge anything that theyre not comfortable with, but ideas need to be supported and *valued* first and foremost. Without new ideas youre just gonna have a project with people who never come up with anything.
                    What does "supported and valued ideas" mean. Any project has a set of goals and these may or may not fully align with the goals of every other contributor.

                    Comment

                    Working...
                    X