Patch Proposed For Adding x86_64 Feature Levels To The Kernel - But It's Likely D.O.A.

[phoronix]

Phoronix: Patch Proposed For Adding x86_64 Feature Levels To The Kernel - But It's Likely D.O.A.

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...

https://www.phoronix.com/news/Linux-Kernel-x86_64-FL-Patch

[jeisom]

So this is just a variation of the existing CFLAGS/MARCH patch that has been around for YEARS that they don't want to add already. Not surprising then.

Edit: Also what kind of end users are they worried about not knowing what they are doing??

[V1tol]

"We don't need that means nobody needs that". Linux developer edition.

[ms178]

I don't get it why nobody tells them some of the obvious benefits of having that patch upstream:

1) It obviously lowers the barrier for novice users who want to compile their own Kernel with this feature. Finding a fitting entry via menuconfig in the CPU submenu is obiously nicer and easier to work with than having to learn about the existence of environment variables and how to use them properly which also complicates the whole build process a little.

2) Having these feature levels opens up the opportunity to clean up the decades of obsolete x86 CPU architectures which are still present in the Kernel. Providing these feature levels as a replacement next to the vanilla x86-64 for compatibility would be a sane baseline. This enables to get rid of the old cruft, providing sane options for all x86 CPUs on the market.

3) It also would provide better CI coverage for actually using these advanced instructions with the Kernel. Having the Kernel compiled with advanced instructions is a great way to find and fix bugs on the compiler and Kernel side which benefits both sides.

4) Unlock the potential for some performance benefits. Only benchmarks on a lot of different systems might tell if it is worth it or not from a performance point of view. At least in theory, it should be a win.

In my view, the x86 cleanup is already a good enough reason to include it.

[xenospace]

I'd love to see what the effects of these feature levels actually are, in benchmarks.

I've also been wondering what effect the LTO support for kernel compilation might have when turning off all of the additional CPU features that are unnecessary for a specific CPU. Surely there could be some performance benefits to trimming off all of the additional functionality for unrelated CPU architectures and then optimizing, like, for instance, turning off all of the AMD related features on a kernel built specifically for a particular intel processor architecture.

I don't really see the harm in allowing the feature though, since intel clear linux, red hat, and cachyos are already shipping x86-v2/v3/v4 compiled packages.

[QwertyChouskie]

Yes, specifying '-march=x86-64-v3' can indeed yield significant performance improvements for CPUs that support it. I could confirm this.

Please allow me a few days, as I will provide a detailed test data report from my own tests after my vacation.

Given that such submissions 'pop up' in the mailing list from time to time, I hope this time we can see it through.

We should have a broad discussion, comprehensive testing and a calm judgment until we reach a final conclusion on whether this modification brings more benefits or drawbacks.

Link: https://github.com/graysky2/kernel_c...tch/issues/100
Suggested-by: WangYuli <[email protected]>
Tested-by: WangYuli <[email protected]>

Best regards,
--
WangYuli

Maybe not DOA if it proves its usefulness.

[NateHubbard]

Edit: Also what kind of end users are they worried about not knowing what they are doing??

Oh haven't you heard? Everyone is always building their own kernel without having the slightest idea what CPU they are using.
Apparently.

[npwx]

Oh haven't you heard? Everyone is always building their own kernel without having the slightest idea what CPU they are using.
Apparently.

While that does seem like a rather poor point, IIRC benchmarks have repeatedly shown basically zero benefit. Any just having 10 users miscompile every month and asking for debugging help can already be a nuissance.

In any case, someone offered to post benchmarks. So let's see if this time, someone can actually demonstrate some benefit.

[jeisom]

I don't get it why nobody tells them some of the obvious benefits of having that patch upstream:

1) It obviously lowers the barrier for novice users who want to compile their own Kernel with this feature. Finding a fitting entry via menuconfig in the CPU submenu is obiously nicer and easier to work with than having to learn about the existence of environment variables and how to use them properly which also complicates the whole build process a little.

2) Having these feature levels opens up the opportunity to clean up the decades of obsolete x86 CPU architectures which are still present in the Kernel. Providing these feature levels as a replacement next to the vanilla x86-64 for compatibility would be a sane baseline. This enables to get rid of the old cruft, providing sane options for all x86 CPUs on the market.

3) It also would provide better CI coverage for actually using these advanced instructions with the Kernel. Having the Kernel compiled with advanced instructions is a great way to find and fix bugs on the compiler and Kernel side which benefits both sides.

4) Unlock the potential for some performance benefits. Only benchmarks on a lot of different systems might tell if it is worth it or not from a performance point of view. At least in theory, it should be a win.

In my view, the x86 cleanup is already a good enough reason to include it.

For 1 it would probably be noted with the "leave alone if you don't know what it does" camp. Most novices are learning about the kernel build process at that point. I don't think 2 is true. This doesn't remove any cruft.

3 is the best reason it would be useful from a development standpoint, kernel and compiler. Can be used for 4 to test whether it can make improvements which lead back to 3 and potentially future optimizations for both.

[betam4x]

Great idea, flawed execution. Example: Current AMD chips support AVX-512, Intel chips do not. It is better to enable the specific features themselves based on the target chip, IMO.