Suggest sending this patch upstream

[Avenger-285714]

Given the project's potential for merging into the main upstream line, it might be worth considering.

While some of these changes might be controversial, we could at least extract the following two parts: *1. Adding 'AMD/Intel' prefixes to configuration names for some existing CPU microarchitectures; 2. Adding support for Generic-x86-64-v2/3/4.

[graysky2]

Last time I posted to lkml no one cared, see: see: https://github.com/graysky2/kernel_compiler_patch/issues/1 For point 1, I am not sure what you mean. For point 2, see https://github.com/graysky2/kernel_compiler_patch/commit/a0e993a2ccfc38a6caa837543ea2a4085b41e252

[Avenger-285714]

point1: like this:

[Avenger-285714]

https://lkml.org/lkml/2012/12/9/49

Since our last discussion was quite a while ago, and our understanding of the Linux kernel project may have evolved, I would like to reopen the discussion on the upstream mailing list, if you and other interested parties are agreeable.

Specifically, I'd like to revisit the two parts I mentioned earlier, as I don't anticipate much controversy around those.

[graysky2]

https://lkml.org/lkml/2024/9/15/186

[Avenger-285714]

Well.

While the upstream developers remain somewhat conservative, there are clear signs that they are open to persuasion.

So let's adjust our code and provide more detailed test data.

[ms178]

Besides potential performance benefits, please also mention a couple more arguments to try to convince the upstream devs. Here are a few:

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, more intuitive and easier to work with than having to learn about the existence of environment variables and how to use them properly which would also complicate the whole build process by a little bit.

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 as options. Providing these feature levels as a replacement next to the vanilla x86-64 for compatibility reasons would provide new sane options for all x86 CPUs on the market from all relevant vendors.

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. I've used this patch myself in the past even without "-mno-avx2" on a reduced config and while I've seen some build issues from time to time, it mostly worked even with these vector instructions as advertised. That heavily depends on the hardware and used drivers, of course.

I wonder if "march=native" should also be included with a sidenote to not use it if the Kernel is meant to be used on a wide range of CPUs with different capabilities. This message should also be part of the description to warn users of the implications. But apart from that potential pitfall, I see nothing wrong in general with providing this option.

[Avenger-285714]

Besides potential performance benefits, please also mention a couple more arguments to try to convince the upstream devs. Here are a few:

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, more intuitive and easier to work with than having to learn about the existence of environment variables and how to use them properly which would also complicate the whole build process by a little bit.
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 as options. Providing these feature levels as a replacement next to the vanilla x86-64 for compatibility reasons would provide new sane options for all x86 CPUs on the market from all relevant vendors.
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. I've used this patch myself in the past even without "-mno-avx2" on a reduced config and while I've seen some build issues from time to time, it mostly worked even with these vector instructions as advertised. That heavily depends on the hardware and used drivers, of course.

I wonder if "march=native" should also be included with a sidenote to not use it if the Kernel is meant to be used on a wide range of CPUs with different capabilities. This message should also be part of the description to warn users of the implications. But apart from that potential pitfall, I see nothing wrong in general with providing this option.

Yes, yes. Please provide your email address so we can Cc you when discussing this matter with upstream.

[ms178]

E-Mail: [email protected]