Don't Look For Gentoo's CPU Optimization Options To Land In The Mainline Linux Kernel

[mekosmowski]

When kernel devs opine that "couple months" == six years, it doesn't inspire confidence. Between this and the recent anti-ZFS API change, it seems like kernel devs don't care about freedom of choice. I thought that part of the driving philosophy behind free (as in freedom) software was to not be told how to use the software.

[wrc1944]

I've been running Gentoo "testing" on three amd64 systems for 15+ years, and started using the gcc-opts patches as soon as they were available many years ago. Never had a problem, and was very pleased when mpagano (gentoo genpatches dev) kindly included them a few years ago in the "gentoo-sources" kernel.

IMO, there's no reason not to include them. Why would one want to compile their kernels without enabling support for every feature your particular cpu was designed to include? Makes little, if any sense.

Keep in mind each cpu selection the patches provide is not a particular maintainers given set of CPU optimizations. Instead, it enables the features and support for the selected cpu that the running version of GCC detects and then provides.

One caveat: It has been reported that selecting your indivual cpu might not always enable ALL possible features, as there may be different chip versions/steppings which may be included under the same selection, or lags in updating the patches themselves.

As I understand it, these days it seems better to just always select "march=native" and let GCC detect and enable all the current features for the cpu it finds. In the past I always selected my specific cpu, but when march=native was introduced it made perfect sense.

[dwagner]

Both involved upstream developers seem to want to keep this matter away from their work item list.

Well, if their argument was wrong that the changes make maintenance considerably harder, then there is also little effort involved in maintaining those changes outside of the mainline kernel.

As others mentioned, it's easy enough to choose one's favorite compiler options already if one is prepared to do so on one's own responsibility.

[microcode]

Maybe Michael could put this to rest for them. :- )
I'm not really satisfied with the bz2-based benchmark, it seems like a bad proxy for kernel performance.

[Thaodan]

Michael did you read everything?
The patch is from Gravsky which is no Gentoo user/dev. But rather maintains linux-ck for arch.

[sophisticles]

All I have to say is look at Open Mandriva, that offers a Zen "optimized" variant of it's distro, both base distro, including kernel, and apps, including updates and as Michael's tests has shown it makes little to no difference from the variant compiled with generic settings.

There's no such thing as a free lunch, if you want significantly faster performance you either need to faster hardware or you need to make substantial changes to the software, a simple patch or compiler optimization has rarely makes an significant difference.

[xiando]

I've been using this patch for years without any ill effects, seems like a bogus reason not to include it and I'm surprised Clear Linux isn't doing something similar for their builds

I've been using the Gentoo patch 5010_enable-additional-cpu-optimizations-for-gcc.patch against kernels for a decades with zero problems. The supposed reasons for not wanting to support more architectures are bullshit, to put it mildly, and they have been for years. The latest "we've said we didn't want this before so that's why we don't want it now" response is typical.

It's interesting to note that if you go into make menuconfig and select "Processor type and features" and "Processor family" you'll find the option of optimizing for a handful of different CPUs. Adding a few more or the option of just using -native, which would work for anyone, is not a lot of work. The arguments against are hogwash, plain and simple. I point this out because it is worth being aware that the option of optimizing your kernel for a specific CPU is not a new proposal. And it's not new to the kernel. It has been a kernel feature for decades. The issue is adding new CPU architectures and preferably the option of using march=native (which basically covers all the CPU architectures including future ones).

"I don't accept the benchmark numbers showing real-world improvements" isn't a valid argument.

"It's not maintainable" is also a bullshit excuse. Add the option of march=native, done. No need to "maintain" that. What, exactly would you need to change or "maintain"? absolutely nothing.

"we need sane defaults" is also a totally idiotic pathetic excuse and not an argument. Nobody's demanded or proposed to make march=native a default. Those CPU specific compiler optimizations are choices, they are options for those who want them. And let's face it, if you're compiling your own kernel in this day and age then you'll probably want that option and you'll probably be able to figure out how to choose it.

As for the latest bullshit "it's been rejected before so we don't want it now", I don't even get why Corentin Labbe feels like he should weight in on that matter at all. He's a maintainer for Allwinner SOCs, not x86-64 systems.

Anyway, for my personal use it doesn't matter that much that the kernel developers insist on excluding an option that so obviously should be there. Downloading a copy of the gentoo experimental patches and applying the additional CPU optimizations is easy enough. And it touches so few files and lines that the same patch applies cleanly to kernel after kernel for years and years and years.

[pmorph]

This would probably have a negative effect on kernel quality and/or development time, already by the added layer of things to consider/test when bug reports are being analyzed. And there would be angry people.. who can't understand why a bug they reported using an exotic combination of optimizations gets so little attention.

[audir8]

It makes sense that kernel devs would want to target x86_64 and that any optimizations should be made available there instead of other places. But really, -march=native is by far the most benign performance GCC flag. -O2, even -O1 will fail occasionally, every other (pgo, lto, -O3) GCC performance (or security) flag is orders of magnitude more fragile than -O2. Compared to any of these -march=native is closer to -Wall.

[milkylainen]

I'd like to counter the reasoning from Ingo Molnar as shown here https://lore.kernel.org/lkml/[email protected]/

1.) "I'm not convinced the numbers are right."

It's as its always been with the kernel. No real performance testing or performance regression handling. It's always been more of the "oops, this was bad" and "oh, we fixed this and now it's faster.". Some sporadic testing do occur. But then it's always contended because of this and that.
This is also how endless crap (yes, asinine spectre and meltdown handling) makes it into the kernel without anyone as much as raising an eyebrow.

A kernel like the Linux kernel should have a qualified performance test suite. An binary that can be built from the kernel tree which can be loaded instead of init to measure the kernel in an undisturbed fashion. Or whatever really.