Linux 6.16 Adds 'X86_NATIVE_CPU' Option To Optimize Your Kernel Build (phoronix.com) 33
unixbhaskar shares a report from Phoronix: The X86_NATIVE_CPU Kconfig build time option has been 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 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."
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."
Re: What? (Score:5, Informative)
Re: What? (Score:5, Informative)
> 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).
amd/intel not the issue (Score:3, Interesting)
Re: (Score:2)
Until now, kernel compilation left some room for portability between different processors within the same family.
Until now? These options have been around forever.
Linux is built with modest hardware in mind (Score:2)
Until now, kernel compilation left some room for portability between different processors within the same family.
Until now? These options have been around forever.
Keep in mind that Linux is built with modest hardware in mind, even repurposed older machines. If one were to say the minimum target is the Intel Core Generation 4, Haswell [wikipedia.org], that would be entirely reasonable for a commercial software product. For Linux, not so much. I would not be surprised if my 64-bit Athlon II, a very early 64-bit, runs the standard download.
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)
Apparently [github.com], it's -march [github.com]. And -mtune also still exists [gnu.org].
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:2)
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:3)
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: (Score:2)
Naw, that's distros that insist on packaging a separate bloody VM with every software package. Gentoo has some bloat in the sense that too many coders feel the need to use enormous libraries but you really don't see conflicts in it anymore unless you start trying to put ~amd64 in package.accept_keywords for everything so you can run the absolute bleeding edge version. Sticking to the stable versions (which are still pretty up to date, this is Gentoo after all) that don't need an entry in package.accept_keyw
Re: What? (Score:4, Interesting)
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:1)
Gentoo users are absolutely not less technical but we are definitely outnumbered. Arch is an easier distro to use, so of course it has more users.
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:What? (Score:4, Informative)
The difference between those and Gentoo is that with the latter you generally must compile your system
Not anymore since 2023. You set "EMERGE_DEFAULT_OPTS=--getbinpkg" and it will fetch pre-buit packages. It will only rebuild locally if you change any USE flag applicable to the package.
Right now the difference between gentoo and other distros might be how convenient gentoo is if you want to use different configure flags, or apply custom patches. Just add one simple line in a config file, or drop a patch in the correct directory, then your config flags and patches are automatically applied at every new version.
Re: (Score:2)
Ah, that's a nice development, thanks.
I might look into it again, as the flags configuration is pretty convenient.
I suppose it is still the most up-to-date thing there is.
Re: (Score:1)
Honestly, I think Arch might be a little ahead of Gentoo on average nowadays, especially if you include the AUR. But it breaks more often last I checked.
Re: (Score:3)
Arch has 93700 packages in AUR while gentoo has 72645 packages in the overlays. But nobody chooses gentoo for "more packages than distro X". It's about tweaking the system. Examples of things to be done with a gentoo:
* activate/deactivate "controversial" features you don't like or pose a security risk e.g. systemd, wayland, pulseaudio/pipewire, polkit.
* mix versions, for example stable everything but latest version of that one specific user software you need e.g. latest Blender.
* control compile options of
Re: (Score:1)
I was talking about in terms of being up to date not how many packages either has. That's a terrible metric since you can't tell what software will be in what package from distro to distro.
Re: (Score:2)
I'm not aware of such data exists but that would be indeed be interesting to read. However for what I can say for gentoo: major packages get updated real quick, sometimes negative time. Recently maybe Firefox 137 was available as update before release notes on mozilla.org. I also regularly get new kernel versions before they're announced on lwn.net.
I agree lesser-known packages can take longer. However in this case gentoo makes it trivial to update it yourself, in particular for minor revisions (where depen
Re: (Score:1)
Yeah, a lot of packages have the option to pull directly from git with only a package.accept_keywords change and the ~amd64 keyword will get you something pretty recent most of the time too. People who don't want to spend all their time in dependency hell learn not to do that too much though.
Yeah, I've got two or three ebuilds in a private overlay for that. I really try not to rely on that for anything I don't actually need to be a version that hasn't hit the repos yet though.
Re: (Score:1)
Yeah, that is a really nice addition. Before that you could still use a dedicated BINHOST or a derivative distro like Calculate-Linux who had their own and get the same result but it's less work since Gentoo has started building and hosting most packages with default USE flags.
Re: (Score:3)
Why can't these code monkeys make simple compiler flag like "query my cpu and apply optimizations"?
There is an assumption that users would like binaries which can be used on other machines. By default when you compile with an amd64 compiler you get code which will work on any amd64. If you use -march you lose that.
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.
Write some SIMD code ... (Score:3)
Re: (Score:2)
I've been coding intrinsics and assembler professionally for two decades. Running isn't the only metric I use, if it was, I wouldn't have bothered to use SIMD at all.
Once x86 went superscalar, a lot of ordinary instructions went into a backwardly compatible support role rather than in a performance role. There's a lot of old tricks we used to use in assembler and in compiler development that is obsolete today. Because ... the behavior is different on the new architecture. It's compatible but not usefully so
Sun compiler -fast flag used to do this (Score:3)
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.
Thankyou editors for once again (Score:2)
showing how useless you are, talking about compiler flags that are not available with zero context on what they actually do. Thank god some technical discussions still happen in the comments.
Here's what I landed on for building for Devuan (Score:2)
(make a new directory, download the kernel tarball into it)
(unpack and cd into sources)
cp /boot/config-`uname -r` ./.config
scripts/config --disable DEBUG_INFO
scripts/config --disable DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT
now do config. lately I am using make oldconfig because I am already using a recent kernel .config as my starting point and I am not asked too many questions. then...
make clean
nice ionice -c 3 make -j$(nproc) \
CCACHE_DIR=$HOME/.local/cache/ccache \
KCFLAGS=' -march=znver3' KCPPFL