New Linux Kernel Code Works On APIC "Decrapification", Suggests Dropping x86 32-bit

There's a lovely new Linux kernel patch series out that's big in working on a major clean-up of the x86 APIC code (or "decrapification" as it's called in the patches) and also bringing up for discussion the idea of killing off x86 32-bit support. It's unlikely the x86 32-bit support will be removed right now, which is "just museum pieces", but as an alternative would be making it SMP-only to at least remove the uni-processor code paths.

Longtime Linux kernel engineer Thomas Gleixner of Intel-owned Linutronix took to cleaning up the x86 APIC code while working on overhauling the kernel's CPU topology evaluation mechanism. He wrote in the patch cover letter:

"While working on a sane topology evaluation mechanism, which addresses the short-comings of the existing tragedy held together with duct-tape and hay-wire, I ran into the issue that quite some of this tragedy is deeply embedded in the APIC code and uses an impenetrable maze of callbacks which might or might not be correct at the point where the CPUs are registered via MPPARSE or ACPI/MADT.

This made me look deeper and the findings were anything but pretty. Redundant per CPU variables, completely unused code, needless complexity all over the place.
...
So I stopped working on the topology stuff and decided to do an overhaul of the APIC code first. Cleaning up old gunk which dates back to the early SMP days, making the CPU registration halfways understandable and then going through all APIC callbacks to figure out what they actually do and whether they are required at all. There is also quite some overhead through the indirect calls and some of them are actually even pointlessly indirected twice. At some point Peter yelled static_call() at me and that's what I finally ended up implementing."

While being frustrated by the x86 32-bit code, which he referred to as for museum wares, while ideally he would like to see the x86 32-bit code removed he acknowledges it's unlikely to happen right now. But a possibility may be making the x86 kernel SMP-only to allow removing the uni-processor (UP) code.

"This builds and boots on 32bit and 64bit, but obviously needs a larger test base especially on those old 32bit systems which are just museum pieces.

I have neither evaluated whether this has a measurable impact, but that's something I leave to the perfomance teams. Definitely less indirect calls in hotpaths are a win by definition.

Talking about those museums pieces and the related historic maze, I really have to bring up the question again, whether we should finally kill support for the museum CPUs and move on.

Ideally we remove 32bit support alltogether. I know the answer... :(

But what I really want to do is to make x86 SMP only. The amount of #ifdeffery and hacks to keep the UP support alive is amazing. And we do this just for the sake that it runs on some 25+ years old hardware for absolutely zero value. It'd be not the first architecture to go SMP=y.

Yes, we "support" Alpha, PARISC, Itanic and other oddballs too, but that's completely different. They are not getting new hardware every other day and the main impact on the kernel as a whole is mostly static. They are sometimes in the way of generalizing things in the core code. Other than that their architecture code is self contained and they can tinker on it as they see fit or let it slowly bitrot like Itanic.

But x86 is (still) alive and being extended and expanded. That means that any refactoring of common infrastructure has to take the broken hardware museum into account. It's doable, but it's not pretty and of really questionable value. I wouldn't mind if there were a bunch of museum attendants actively working on it with taste, but that's obviously wishful thinking. We are even short of people with taste who work on contemporary hardware support...

While I cursed myself at some point during this work for having merged i386/x86_64 back then, I still think that it was the correct decision at that point in time and saved us a lot of trouble. It admittedly added some trouble which we would not have now, but it avoided the insanity of having to maintain two trees with different bugs and "fixes" for the very same problems. TBH quite some of the horrors which I just removed came out of the x86/64 side. The oddballs of i386 early SMP support are a horror on their own of course.

As we made that decision more than 15 years [!] ago, it's about time to make new decisions.

Vented enough.

I'm sure that I broke things on the way, but we can't just continue with the current mess and add duct tape over hay-wire over duct-tape over hay-wire forever. At some point we need to bite the bullet and get rid of the historical nonsense even if it's painful. That point is now."

Well said.

Old "museum pieces" from the early days of Phoronix.

For now this set of 58 patches work on the "decrapification" of the x86 APIC Linux code. It will be interesting to see if it ultimately has an impact on performance as noted as a possibility in the cover letter.