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

[coder]

Once the first patch of this kind is accepted, there will be hundreds of patches from people with their specific magic performance formula for their super niche kernel.

The solution isn't to ban any model-specific optimizations, but rather to devise a scheme to make them manageable. glibc has done something like this, and I'm not talking about the ISA feature level. I believe it has a mechanism where it can load a custom set of symbols for your CPU.

People here talk like Linux will be around forever and has nothing to worry about from other operating systems, but if Linux turns its back on too many performance opportunities, its days are numbered.

[Sonadow]

The solution isn't to ban any model-specific optimizations, but rather to devise a scheme to make them manageable. glibc has done something like this, and I'm not talking about the ISA feature level. I believe it has a mechanism where it can load a custom set of symbols for your CPU.

People here talk like Linux will be around forever and has nothing to worry about from other operating systems, but if Linux turns its back on too many performance opportunities, its days are numbered.

This can easily be done if it's an OS with a very stable kernel like Windows.

OS maker ships the OS with the standard kernel, vendor issues an installer that installs various ISA-level patches and extensions into the kernel as kernel drivers. And because the kernel is stable and the OS has long support lifespans, the installer works across multiple versions of the OS and kernel, which means vendor only needs to update it when a breaking change is made like every four or five years.

[NotMine999]

The solution isn't to ban any model-specific optimizations, but rather to devise a scheme to make them manageable. glibc has done something like this, and I'm not talking about the ISA feature level. I believe it has a mechanism where it can load a custom set of symbols for your CPU.

People here talk like Linux will be around forever and has nothing to worry about from other operating systems, but if Linux turns its back on too many performance opportunities, its days are numbered.

I believe ARM code in the Linux kernel uses (or can use) the DTS process. Based on my own past experience, it seemed to work for some ARM devices that I had that ran Linux code and used the DTS process; Linux on Kirkwood-based ARM SoC devices.

What about a similar process for all the SoC-specific 'quirks' of the billions upon billions of ARM CPU implementations that are out there?

Maybe 'quirks' is a misleading word to use here, but it is a word that is used within the Linux kernel codebase to describe device-specific 'adjustments' that are sometimes needed to make some hardware work under Linux.

FWIW I am just tossing out an idea for discussion. I am not involved in Linux kernel development or maintenance in any way.

[marios]

Once the first patch of this kind is accepted, there will be hundreds of patches from people with their specific magic performance formula for their super niche kernel. Just look at whats available on github; I would not want to maintain that insane mess of different config options either. And also not deal with the bugreports caused by these.
I do understand the kernel maintainers position very well.

The kernel is full of "insane mess of different config options" already. Is it a problem? No! Why? Because infrastructure that makes it maintainable exists. Look at drivers, filesystems, crypto stuff (some architecture specific implementations btw), vulnerability mitigations (heavily micro-architecture specific. Really why did nobody cry about the maintainability of those patches?). All of these things are in the kernel as they should be. The micro-architecture specific optimisations is just another area where something similar has to happen.

[Volta]

Are we talking about old hardware here?

No.

Stop making it so easy proving to the world how much of a joke you are. It's no challenge.

Where's Windows ARM support (at comparable level to Linux)? You were talking about maintainers in case you forgot. Linux supports much more hardware than closed source OSs ever dreamed of. Calling maintainers a joke makes you look like a brainless fool. However, I'd like to have such optimizations mainlined, but I'm not a maintainer, so it's not up to me to deal with this code. Let's check how much of a joke you are:

Linux support for ARM devices:

• Acorn Archimedes and RiscPC series (original machines were supported in 2.6.22⁾
• Allwinner
• Apple M series processors
• Broadcom VideoCore
• DEC StrongARM
• Samsung Exynos
• Marvell (formerly Intel) XScale
• Sharp Zaurus
• HiSilicon
• iPAQ
• Palm, Inc.'s Tungsten Handheld
• Gamepark Holdings' GP2X
• Open Pandora
• MediaTek
• Nokia 770 Internet Tablet
• Nokia N800
• Nokia N810
• Nokia N900
• Nomadik
• NovaThor
• gumstix
• Sony Mylo
• Qualcomm Snapdragon
• Nvidia Tegra
• TI OMAP
• Psion 5, 5MX, Series 7, netBook
• Rockchip
• Some Models of Apple iPods (see iPodLinux)
• OpenMoko Neo 1973, Neo FreeRunner
• Freescale's (formerly Motorola's) i.MX multimedia processors

Windows 11 support for AMR devices (get ready for a joke):

• Qualcomm Snapdragon

[Volta]

Anyone arguing in good faith would be smart enough to recognize that what Volta said was shorthand for "Open source developers are still supporting hardware that closed-source vendors dropped support for years ago" and/or "Open source developers are still maintaining competitors to software products that closed-source vendors dropped support for years ago" and address the actual point, rather than making a fool of themselves thinking they've scored a win by attacking a strawman they constructed by intentionally reading an unintended meaning from a bit of lazy grammar.

Thanks for clarification. It's exactly what I meant.

[Volta]

This can easily be done if it's an OS with a very stable kernel like Windows.

We're not talking about turning Linux into insecure legacy mess with half of its performance.

[wsippel]

Come back and tell us that after connecting a QLogic QLGE card. Or 98% of the world's Android phones that use RNDIS for tethering.

You are a mentally challenged clown.

It would be QLogic's job to fix the QLGE driver, they submitted it for inclusion. Alas, QLogic no longer exists, and Marvell clearly doesn't care. From what I can tell, the Windows drivers haven't been updated in many, many years, either.

[Weasel]

Where's Windows ARM support (at comparable level to Linux)?

No idea. Who cares? I hate ARM anyway.

I was talking in general, not Linux kernel specifically; this is just one example. They are always obsessed with simplicity and "maintainability" and basically lazy to have it in, holding progress back even for contributors who contribute the god damn optimizations and code. How does losing 40% performance feel like to you because of some asshat maintainer who "doesn't find it useful" (as if he's the one using it!!! the nerve!!!)

So spare me the typical classic bullshit "where's your patch then?" talk, anyone who ever said that proves how little experience he has contributing anything to some open source where those clowns will simply ignore or reject it. Or that they're not even programmers in the first place.

Windows is a fucking joke but that's for completely other reasons. That platform (API) is good though.


BTW: https://www.phoronix.com/news/Linux-...-UMS-DRM-Infra

Open source maintainers are great, eh?

[Weasel]

What? That's a good thing.

ARM is already such a royal mess where mainline kernels cannot be used with almost every ARM system to date, and you want them to pull in more SoC variant-specific patches?

Can you imagine what will happen if, for example, board vendors like Asus, MSI etc license Intel/AMD processors, make changes to them, and then submit patches for every single change they make to the processors back to the kernel?

Actually, just imagine what will happen if all of them submitted requests to Microsoft to include their vendor-specific x64 optimisations and customisations into the Windows kernel. Microsoft will probably just tell them to go pound sand.

On the other hand, if the vendors compiled these as driver DLLs and requested Microsoft to include them with Windows, Microsoft will probably be more accommodating.

Well that makes more sense, but they can't do that on Linux, because it doesn't have a stable kernel ABI.

It's not about being monolithic or not. It could very well be monolithic (modules loaded in same address space, as libraries) and have a stable ABI if they wished.

I actually prefer monolithic because it has more performance, but I'm not a fan of unstable ABI at all.