Linux 6.16 Adds 'X86_NATIVE_CPU' Option To Optimize Your Kernel Build - Slashdot

Linux 6.16 Adds 'X86_NATIVE_CPU' Option To Optimize Your Kernel Build - Slashdot
Close
binspam
dupe
notthebest
offtopic
slownewsday
stale
stupid
fresh
funny
insightful
interesting
maybe
offtopic
flamebait
troll
redundant
overrated
insightful
interesting
informative
funny
underrated
descriptive
typo
dupe
error
177817755
story
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."
You may like to read:
Cloudflare CEO: Football Piracy Blocks Will Claim Lives
Linus Torvalds Expresses His Hatred For Case-Insensitive File-Systems
Denmark Is Dumping Microsoft Office and Windows For LibreOffice and Linux
What the Linux Desktop Really Needs To Challenge Windows
Four More Tech Bloggers Are Switching to Linux
Linus Torvalds Rejects RISC-V Changes For Linux 6.17 For Being Late and 'Garbage'
Submission: Linux 6.16 Adds "X86_NATIVE_CPU" Option To Optimize Your Kernel Build
SpaceX Starship Blasts Off In Ninth Test Flight
This discussion has been archived.

No new comments can be posted.
Linux 6.16 Adds 'X86_NATIVE_CPU' Option To Optimize Your Kernel Build
More
Linux 6.16 Adds 'X86_NATIVE_CPU' Option To Optimize Your Kernel Build
Comments Filter:
All
Insightful
Informative
Interesting
Funny
The Fine Print:
The following comments are owned by whoever posted them. We are not responsible for them in any way.
Re: What?
Score:
, Informative)
by
Kohenkatz
( 1166461 )
writes:
on Tuesday May 27, 2025 @09:53PM (
#65409333
Journal
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."
Parent
Share
Re: What?
Score:
, Informative)
by
bill_mcgonigle
( 4333 )
writes:
on Tuesday May 27, 2025 @10:00PM (
#65409353
Homepage
Journal
> 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).
Parent
Share
amd/intel not the issue
Score:
, Interesting)
by
Anonymous Coward
writes:
The issue is various flavors of SIMD instructions and other primitives (e.g. cmpxchg16b) that have been added to x86-64 in the last few decades. A few years ago these were clumped together into feature sets (v1, v2, v3) because it's not practical to ship 100 different kernels with Ubuntu for example. Almost all distributions still target v1. RHEL 9 requires x86-64-v2, RHEL 10 will require v3. That's on top of the fact that different CPUs prefer different kinds of code for optimum performance (e.g., an Atom
Re:
Score:
by
drinkypoo
( 153816 )
writes:
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:
by
drnb
( 2434720 )
writes:
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:
by
drinkypoo
( 153816 )
writes:
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:
by
Mr. Dollar Ton
( 5495648 )
writes:
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:
by
The Mighty Buzzard
( 878441 )
writes:
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:
by
Mr. Dollar Ton
( 5495648 )
writes:
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:
by
The Mighty Buzzard
( 878441 )
writes:
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:
, Interesting)
by
insecuritiez
( 606865 )
writes:
on Tuesday May 27, 2025 @11:36PM (
#65409491
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.
Parent
Share
Re:
Score:
by
Mr. Dollar Ton
( 5495648 )
writes:
Good to hear that. And yes, the arch knowledge base is excellent.
Re:
Score:
by
The Mighty Buzzard
( 878441 )
writes:
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:
by
drinkypoo
( 153816 )
writes:
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:
, Informative)
by
test321
( 8891681 )
writes:
on Wednesday May 28, 2025 @05:15AM (
#65409855
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.
Parent
Share
Re:
Score:
by
Mr. Dollar Ton
( 5495648 )
writes:
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:
by
The Mighty Buzzard
( 878441 )
writes:
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:
by
test321
( 8891681 )
writes:
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:
by
The Mighty Buzzard
( 878441 )
writes:
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:
by
test321
( 8891681 )
writes:
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:
by
The Mighty Buzzard
( 878441 )
writes:
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:
by
The Mighty Buzzard
( 878441 )
writes:
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:
by
drinkypoo
( 153816 )
writes:
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:
by
OrangeTide
( 124937 )
writes:
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:
by
drnb
( 2434720 )
writes:
Write some SIMD code, SSE, AVX. Now run the code across a wide variety of different generations of CPUs. Its enlightening.
Re:
Score:
by
OrangeTide
( 124937 )
writes:
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:
by
madbrain
( 11432 )
writes:
on Tuesday May 27, 2025 @10:06PM (
#65409373
Homepage
Journal
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.
Share
Thankyou editors for once again
Score:
by
thegarbz
( 1787294 )
writes:
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:
by
drinkypoo
( 153816 )
writes:
(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
Related Links
Top of the:
day
week
month
286
comments
Linus Torvalds Expresses His Hatred For Case-Insensitive File-Systems
277
comments
Denmark Is Dumping Microsoft Office and Windows For LibreOffice and Linux
231
comments
What the Linux Desktop Really Needs To Challenge Windows
197
comments
Four More Tech Bloggers Are Switching to Linux
183
comments
Linus Torvalds Rejects RISC-V Changes For Linux 6.17 For Being Late and 'Garbage'
next
SpaceX Starship Blasts Off In Ninth Test Flight
137
comments
previous
Cloudflare CEO: Football Piracy Blocks Will Claim Lives
48
comments
Slashdot Top Deals
He's like a function -- he returns a value, in the form of his opinion.
It's up to you to cast it into a void or not.
-- Phil Lapsley
Close
Working...