A patch was sent out on Sunday for adding new Linux kernel configuration options for tuning the kernel build to different x86_64 micro-architecture feature levels. The intent is on generating kernel builds that are faster for use on modern Intel and AMD systems. However, this patch is likely to not be accepted in the mainline kernel and has already been criticized upstream Linux kernel developers.

[1]The proposed patch adds the x86_64 micro-architecture feature levels v2 / v3 / v4 as new Kconfig options if wanting to cater to them when building the kernel with modern GCC and LLVM Clang compilers. It's just some Kconfig logic to then set the "-march=x86-64-v4" or similar compiler options for the kernel build.

While the x86_64 micro-architecture feature level use can make a great deal better performance for compiling application code, for the Linux kernel the benefits are likely much less. As a reminder x86_64-v2 roughly correlates to Intel Nehalem and AMD Bulldozer and newer with assuming SSE4.1/SSE4.2 and other similar instructions. The x86_64-v3 is for Intel Haswell and newer or AMD Excavator and newer with AVX/AVX2, BMI2, and other newer instructions. The x86_64-v4 feature level is what adds AVX-512.

For the Linux kernel there is already hand-tuned Assembly code where relevant and compiler optimizations tend to make less of a difference than optimized application/user-space code.

[2]

Intel engineer Dave Hansen responded to the proposed patch with:

"If these are going to be exposed to end users, we need *some* kind of help text that helps end users select among these options and what the pitfalls are.

I actually don't have the foggiest idea what an "AMD x86-64 CPU with v2 instructions" even is. Even saying "AMD x86-64 CPU" isn't super helpful because "AMD x86_64" is kinda a generic way to refer to all the 64-bit x86 CPUs, Intel included.

...

So, taking a step back: Please convince us that this is something we want to expose to end users in the first place, as opposed to having them hack makefiles or just allowing users a string instead of using the existing CONFIG_M* Kconfig options.

Then, we can discuss the structure of these options. Should these "versions" be new "Processor family" options? Or, should they be _instead_ of selecting a "Processor family""

And then went on to providing feedback on the proposed logic itself. Hansen later added:

"Oh, gah, and I just realized that this is doing "-march" and not "-mtune". So this really can build binaries that won't even run on older CPUs.

That's just mean.

So there needs to be a lot more justification before we go down this road."

AMD engineer Borislav Petkov responded with:

"Patches like this one appear off and on on the mailing list and each time I ask what's the upside of maintaining this complexity?

And everytime I get no reply or random handwaving. That's because -march settings have no noticeable effect on kernel code generation. Because the kernel code is already pretty much optimized when generated by the compiler and all those flavors don't bring anything additional.

So this is not going anywhere. But hey, I'm always open to nice surprises..."

So as it stands now, it's looking like this proposed patch doesn't have enough justification or interest from upstream kernel developers to make it mainline. Especially when the KCFLAGS/KCPPFLAGS environment variables can already be set with "-march=x86-64-v4" for example if desired to achieve the same impact.



[1] https://lore.kernel.org/lkml/W22JX8eWQctCiWIDKGjx4IUU4ZgYmKa1zPOZSKHHVZ74zpUEmVV1VoPMMNcyc-zhraUayW0d4d7OIUYZHuiEqllnAc1tB8DthZahsHZuw0Y=@proton.me/T/#m7d06e8f30c73f1d5d45e44ddab048195b0ab625e

[2] https://www.phoronix.com/image-viewer.php?id=2024&image=cpus_lrg