Linux 6.16 Adds 'X86_NATIVE_CPU' Option To Optimize Your Kernel Build (phoronix.com)
(Tuesday May 27, 2025 @11:30PM (BeauHD)
from the new-options dept.)
- Reference: 0177817755
- News link: https://linux.slashdot.org/story/25/05/27/2223207/linux-616-adds-x86nativecpu-option-to-optimize-your-kernel-build
- Source link: https://www.phoronix.com/news/Linux-6.16-X86_NATIVE_CPU
[1]unixbhaskar shares a report from Phoronix:
> The X86_NATIVE_CPU Kconfig build time option has been [2]merged for the Linux 6.16 merge window as an easy means of enforcing "-march=native" compiler behavior on AMD and Intel processors to optimize your kernel build for the local CPU architecture/family of your system. For those wanting to "-march=native" your Linux kernel build on AMD/Intel x86_64 processors, the new [3]CONFIG_X86_NATIVE_CPU option can be easily enabled for setting that compiler option on your local kernel builds.
>
> The CONFIG_X86_NATIVE_CPU option is honored if compiling the Linux x86_64 kernel with GCC or LLVM Clang when using Clang 19 or newer due to a compiler bug with the Linux kernel on older compiler versions. In addition to setting the "-march=native" compiler option for the Linux kernel C code, enabling this new Kconfig build option also sets "-Ctarget-cpu=native" for the kernel's Rust code too.
"It seems interesting though," comments unixbhaskar. "If the detailed benchmark shows some improvement with the option selected, then distros might start to adopt it for their flavor."
[1] https://slashdot.org/~unixbhaskar
[2] https://www.phoronix.com/news/Linux-6.16-X86_NATIVE_CPU
[3] https://lore.kernel.org/lkml/aDL66Kw0auSQQrs-@gmail.com/
> The X86_NATIVE_CPU Kconfig build time option has been [2]merged for the Linux 6.16 merge window as an easy means of enforcing "-march=native" compiler behavior on AMD and Intel processors to optimize your kernel build for the local CPU architecture/family of your system. For those wanting to "-march=native" your Linux kernel build on AMD/Intel x86_64 processors, the new [3]CONFIG_X86_NATIVE_CPU option can be easily enabled for setting that compiler option on your local kernel builds.
>
> The CONFIG_X86_NATIVE_CPU option is honored if compiling the Linux x86_64 kernel with GCC or LLVM Clang when using Clang 19 or newer due to a compiler bug with the Linux kernel on older compiler versions. In addition to setting the "-march=native" compiler option for the Linux kernel C code, enabling this new Kconfig build option also sets "-Ctarget-cpu=native" for the kernel's Rust code too.
"It seems interesting though," comments unixbhaskar. "If the detailed benchmark shows some improvement with the option selected, then distros might start to adopt it for their flavor."
[1] https://slashdot.org/~unixbhaskar
[2] https://www.phoronix.com/news/Linux-6.16-X86_NATIVE_CPU
[3] https://lore.kernel.org/lkml/aDL66Kw0auSQQrs-@gmail.com/
Sun compiler -fast flag used to do this (Score:2)
by madbrain ( 11432 )
To some degree. It would expand to a number of code generation options, resulting in binaries only guaranteed to run on the local host CPU. Whether they were the most optimal options for your application on that CPU is a different story.
Re: What? (Score:2)
Until now, kernel compilation left some room for portability between different processors within the same family. For example, you could build the kernel on an Intel processor and then run it on an AMD processor, or switch between different generations of processors. By default that's still going to be true, but this option allows you to say "this kernel will only be used on this exact processor, so there's no need to keep anything for other processor, generations or brands."
Re: (Score:2)
> so there's no need to keep anything for other processor, generations or brands
Also you can use the cpu instructions that you have instead of the least-common denominator set of instructions in the class. Compiler support may vary.
Back in the day we'd get a reliable 15-20% performance/capacity boost by deploying on gentoo with CPU tunings to the hardware (vs. Redhat development boxes).
Re: (Score:2)
It used to be that your system would naturally produce 64 bit binaries, but the exact specifics of what you got out (what processor features it would make use of and/or require) were based on the options you chose. I used to have opinions on which flags mattered which would have been interesting when I used to run Gentoo, a bunch of years ago. Or, for that matter, when I was building gnu tools for my sun4.
(some googling occurs)
[1]Apparently [github.com], [2]it's -march [github.com]. And [3]-mtune also still exists [gnu.org].
[1] https://github.com/Frogging-Family/linux-tkg
[2] https://github.com/graysky2/kernel_compiler_patch
[3] https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html
Re: (Score:2)
You have mechanisms of varying convenience for tuning compilation flags on packages and rebuilding them for your system in every major distro. The difference between those and Gentoo is that with the latter you generally must compile your system, so you might as well do it, while the former let you, but even if you're very enthusiastic, you end up doing it when you can't live without it.
Nothing stops you, for example, from partially or fully rebuilding your debian and its less-flexible semi-commercial clone
Re: (Score:1)
Okay, so here's the deal. That was never a Gentoo problem, that was a you problem. Same as it was a me problem when I first tried Gentoo. You were configuring under false assumptions in an ill advised way for a desktop box.
See, if you're slapping it on a server you know exactly what software is going to be on it and if you ever change it you're going to spend all day changing things anyway. In that case it's perfectly fine to try and optimize out things you don't need on every package if that blows your ski
Re: (Score:2)
it is a software incompatibility problem that isn't related to me and you.
It is the reason why every piece of "run anywhere" software is a 2+ TB bloat these days, they carry their dependencies with them.
Re: What? (Score:2)
The loss of the Gentoo wiki was terrible. Fortunately itâ(TM)s mostly back now. In the intervening years though Arch documentation and users have become the best source of technical information for configuring and troubleshooting. And I say this as a diehard Gentoo user for 20(!) years. I donâ(TM)t think this is because Gentoo users are any less technical, but they seem vastly outnumbered by Arch users.
Re: (Score:2)
Good to hear that. And yes, the arch knowledge base is excellent.
Re: (Score:2)
I get a lot of good info from the arch wiki now, often while just searching but increasingly on purpose. the Debian Wiki continues to be worthwhile as well.
I think I'll just rebuild my kernel and see what that does for the war.
Re: (Score:2)
There are now many implementations of X64 that are only superficially compatible with the base architecture, but behave very differently from a compiler's point of view.