64-bit ARM Linux Kernel Against CPU-Specific Optimizations: "Pretty Unmaintainable"

[phoronix]

Phoronix: 64-bit ARM Linux Kernel Against CPU-Specific Optimizations: "Pretty Unmaintainable"

While micro-architecture specific optimizations are rather common place within the Linux x86_64 kernel for various Intel and AMD CPU families with various performance tricks, the ARM64 Linux kernel maintainers are against introducing new micro-architecture specific optimizations as it affects new ARM processors...

https://www.phoronix.com/news/ARM64-Linux-No-Uarch-Opts

[coder]

That's a shame. I'd expect there should be some way to abstract and organize these patches that would help address the maintainability questions.

This problem is only going to get worse, with all the RISC-V cores coming out of the woodwork. IMO, they really should have a good think about how to do something similar to glibc's approach of applying CPU-specific symbol overrides (IIUC).

Not to get all conspiratorial, but with Rutland being an ARM employee, he would have a conflict of interest with respect to optimizations for 3rd party cores. Should he really have a say? Deacon seems to be ex-ARM, AFAICT.

[jeisom]

That seems, annoying. 1.4x is well beyond margin of error. I wonder if it was tested/would work on other aarch64 systems like Apple's(The prefer 16k though 4k is supported) and Qualcomm's?

[jeisom]

Not to get all conspiratorial, but with Rutland being an ARM employee, he would have a conflict of interest with respect to optimizations for 3rd party cores.

Could lead to less upstreaming if there is a feeling of favoritism and "it won't get merged anyway" sentiment as well

[sobkas]

ARM already have big problem with upstreaming of support for various boards/micro-architectures. Maintainers should encourage sending patches and help in merging them otherwise no one will use mainline ARM tree if relevant patches don't land there. Instead fragmentation of ARM support between various forks will only grow. This is also big problem for distributions, as there are too many forks and single arm kernel is not possible, there are distribution forks whose only purpose is to add specific board support.

[timofonic]

Do they mean AmpereOne is very buggy?

[X_m7]

I wonder how the x86_64 kernel maintainers handle the complexity of micro-architecture specific optimizations, I guess they might actually be able to just throw manpower at it given how popular that architecture is.

[ms178]

I wonder how the x86_64 kernel maintainers handle the complexity of micro-architecture specific optimizations, I guess they might actually be able to just throw manpower at it given how popular that architecture is.

They refuse to do so. Graysky's micro-architecture patch (that allows x86 architecture tuning) was shot down several times over the last couple of years. As a result, several distros simply use that patch in their downstream Kernel. I personally have been using that for years now.

The reasoning was laid down by Ingo Molnar here: https://lore.kernel.org/lkml/[email protected]/

As we have the x86-feature levels nowadays, there is an argument that concentrating on these four feature levels in the Kernel is a more maintainable base worth optimizing for.

[marios]

Those that say "it is unmaintainable" should start the discussion on "How can we make it maintainable?". Leaving performance behind should never be an option.

[Weasel]

As much as I hate ARM, this does suck.

This is why open source maintainers are a joke.