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

[ms178]

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.

That first point of view would be ignorant of the user experience, hence it should be pointed out to them that easing the burden matters for some users that still want to make better use of their hardware. That is a valid concern that Kernel devs should care about, IMHO.

The cruft which I was refering to is all of these obsolete entries of CPU architectures from the late 90s that nobody cares about any longer but that still pollute the CPU menu entry and the Makefiles. It might not be much in terms of lines of code, but having five entries (4 x feature levles plus march=native) would bring some order in there and cover all x86 CPUs for the forseeable future from all x86 vendors. This would be a nice cleanup in my opinion.

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.

I find that convincing as well. I was even brave enough to not use "mno-avx2" to actually use that instruction set on my reduced config. And apart from some build problems, this used to work fine on my system. There might be even more convincing arguments. But the maintainers want to hear these arguments, hence someone pitching the idea should tell them.

[Daktyl198]

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.

Do you have any links to prior benchmarks?

[skeevy420]

It´s funny how two pepole are against the same things but contradict each other in the mailing list.

The 1st argument against it is, the user is stupid does not know what cpu he has, and compiles a kernel that will not boot.

The 2nd argument is , the compiler is stupid and allways builds the same code so the -march flag is not needed.

So this?

[ms178]

I run CachyOS on both my workstation and media server so I don't have to worry about optimizations any longer. Nor do I have to worry about OpenZFS support as it's also integrated into CachyOS. So unless you have some specific reason for further optimizations or non-standard features I'd just just make life easier and switch to CachyOS. That way you can concentrate on your work and play, instead of kernel compilation.

One less patchset to worry about would ease the burden of the patch maintainer and all donwstream users.

[erniv2]

It´s funny how two pepole are against the same things but contradict each other in the mailing list.

The 1st argument against it is, the user is stupid does not know what cpu he has, and compiles a kernel that will not boot.

The 2nd argument is , the compiler is stupid and allways builds the same code so the -march flag is not needed.

[the-burrito-triangle]

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.

Well, you're not wrong. That said, Rocket Lake (RKL) and Tiger Lake (TGL) do support AVX512F and a few other "optional" AVX512 instructions. Alder Lake _did_ support AVX512 on the P cores, but moving threads to E cores lead to obvious issues and it was disabled from that point on.

At any rate, I think this feature shouldn't be as generic as x86_64_v2, v3, v4, etc., and instead, specifically state the instruction sets being optimized for in the compiler or at least state a subset of CPU generations that have a _larger_ overlap of modern instructions like TGL/RKL and ZEN4/5. Otherwise it becomes too generic to make it worthwhile. Though, we don't want to be _too_ specific either (e.g., say ZEN4/5 only). There is a delicate middle ground that needs to be found that adds as much optimization for the largest subset of CPUs without trying to support everything under the sun. Intel's Clear Linux shows that optimizing for a more modern minimum baseline has tangible benefits for those running newer HW.

[muncrief]

I run CachyOS on both my workstation and media server so I don't have to worry about optimizations any longer. Nor do I have to worry about OpenZFS support as it's also integrated into CachyOS. So unless you have some specific reason for further optimizations or non-standard features I'd just just make life easier and switch to CachyOS. That way you can concentrate on your work and play, instead of kernel compilation.

[jeisom]

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.

Unfortunately the benchmarks argument is usually on limited platforms of like, oh I don't see any benefit on my system. That said usually the times I do hear of a benefit it is usually is a small workload situation and doing thorough testing is way harder than it might sound.

Thorough Benchmarks would be good though.

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

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