New Linux Patch Establishes "CONFIG_X86_64_NATIVE" For -march=native Kernel Builds

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
  • phoronix
    Administrator
    • Jan 2007
    • 67152

    New Linux Patch Establishes "CONFIG_X86_64_NATIVE" For -march=native Kernel Builds

    Phoronix: New Linux Patch Establishes "CONFIG_X86_64_NATIVE" For -march=native Kernel Builds

    Last week I wrote about Linux patches cleaning up x86 32-bit kernel builds for x86_64 CPUs. The new iteration of those patches were sent out today, including the addition of a patch adding the CONFIG_X86_64_NATIVE Kconfig tunable for enabling "-march=native" kernel builds to cater your optimized kernel compilation for the CPU on which you are building the kernel...

    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
  • ahrs
    Senior Member
    • Apr 2021
    • 554

    #2
    Why limit it just to -march=native instead of including a KConfig for all of the micro-architecture's like graysky's patches do?


    I often build kernels for another machine where I can't use -march=native because that machine is a different architecture but I still want to target for that micro-architecture specifically for whatever 0.1ms extra performance this may give me.

    Comment

    • intelfx
      Senior Member
      • Jun 2018
      • 1083

      #3
      Originally posted by ahrs View Post
      Why limit it just to -march=native instead of including a KConfig for all of the micro-architecture's like graysky's patches do?

      I often build kernels for another machine where I can't use -march=native because that machine is a different architecture but I still want to target for that micro-architecture specifically for whatever 0.1ms extra performance this may give me.
      I dunno, ask Torvalds.

      If he's that cranky about three microarchitecture levels, imagine what's going to happen should someone send him a patch for all possible -marches.

      Comment

      • erniv2
        Senior Member
        • Apr 2022
        • 267

        #4
        He gave an awnser to that, he does not want that complexity cause in the end you can´t know what cpuid features your target cpu has if you cross compile so you use the standard option and if you compile on the same cpu and want to squezze performance you use native.

        Comment

        • Espionage724
          Senior Member
          • Sep 2024
          • 319

          #5
          Sounds like something that should have existed years ago (figured an appeal for compiling a kernel for your system would also include compiling it tuned to your CPU)

          I either roll with the default out-the-box kernel, or occasionally entertain Liquorix or XanMod for theoretical gaming improvements (can't say I ever noticed anything real-world different vs default with general power saving stuff disabled up to Ubuntu 24.04.1). Haven't had a need to compile my own kernel in years.
          Last edited by Espionage724; 10 December 2024, 05:18 PM.

          Comment

          • edxposed
            Senior Member
            • Jan 2023
            • 306

            #6
            Unless it is possible to automatically disable compile-time mitigations that are determined to be unaffected based on the native CPU, this seems pointless. People can already do the same thing with KCFLAGS=-march=native.

            Comment

            • 6SixTy
              Junior Member
              • May 2024
              • 1

              #7
              Someone tell Linus that almost every other ISA out there has some version of the x86-64 version levels for as long as they have existed. Personally just very tired of seeing random architecture revisions in the Kconfig.

              Comment

              • ahrs
                Senior Member
                • Apr 2021
                • 554

                #8
                Originally posted by erniv2 View Post
                He gave an awnser to that, he does not want that complexity cause in the end you can´t know what cpuid features your target cpu has if you cross compile so you use the standard option and if you compile on the same cpu and want to squezze performance you use native.
                You know what features it has because nobody in their right mind builds a kernel with some foreign -march= setting without first checking that the architecture is what you think it is (It would be a cool feature if /proc/cpuinfo could list the micro-architecture name that GCC would report for -march=native)

                Comment

                • Phoronos
                  Senior Member
                  • Mar 2024
                  • 160

                  #9
                  Originally posted by ahrs View Post
                  You know what features it has because nobody in their right mind builds a kernel with some foreign -march= setting without first checking that the architecture is what you think it is (It would be a cool feature if /proc/cpuinfo could list the micro-architecture name that GCC would report for -march=native)
                  Your idea is bad, too complex, too prone to errors and bugs... BAD BAD BAD

                  Comment

                  • erniv2
                    Senior Member
                    • Apr 2022
                    • 267

                    #10
                    Originally posted by ahrs View Post

                    You know what features it has because nobody in their right mind builds a kernel with some foreign -march= setting without first checking that the architecture is what you think it is (It would be a cool feature if /proc/cpuinfo could list the micro-architecture name that GCC would report for -march=native)
                    No you won´t know it simple example you run a vm and want to compile a kernel, but then some of the cpuid features get filtered by KVM as example the standard kernel will run the native one or v2 v3 v4 kernel will not boot in that vm, thats probably a simplified example but it could happen.

                    Comment

                    Working...
                    X