Thomas Glexiner of Linutronix (now owned by Intel) has posted 58 patches for review into the Linux kernel, but they’re only the beginning! Most of the patches are just first steps at doing more major renovations into what he calls “decrapification”. He says:
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.
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.
He also, at one point, (half-heartedly) argues for the removal of 32-bit x86 code entirely, arguing that it would simplify APIC code and reduce the chance for introducing bugs in the future:
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.
Linus responded to one of the patches, saying “I’m cheering your patch series”, but has obviously diplomatically not acknowledged the plea to remove 32-bit support.
How much would that lighten the kernel load, and potentially speed it up, doing a simple delete of all 32-bit code?
Given that 32bit has a hard limit of 4GB of RAM, it can’t run anything that requires more than a terminal shell to run and none of the security protections like memory address randomization.
Copy and send the 32bit code to someone for archive and historical purposes, then do a Select All and push delete, erase the code fron the kernel file.
We had graphics, TCP/IP, and all that jazz, back on the 486, ya know.
Back in my day you could had a bit in yoir hand. Sogh vaccum tube days.
You can still run Gentoo on a 486. I don’t recommend it.
You could distcc the system so that a stronger system does the cross-compiling… but you’re right.
Most people today wouldn’t call what we had on the 486 “graphics”, but I still remember how excited I was when we got our super VGA monitor.
Services like TCP/IP are daemons, they use Kb, it can be used as a very basic simple web server with only a shell to configure everything.
I am talking about on 32bit hardware, install a new release of any open source operating system, try using the latest release of a GUI web brwser Firefox or Chromium and see how well it runs, compared to even a dual core with 8GB 64bit OS.
Just out of curiosity, what difference would PAE make in this argument? What is the memory limit on a PAE-enabled kernel? What other differences would it make?
I doubt there would be a measureable benefit: after all, the kernel is already compiled without 32-bit support, and the code related to it just doesnt exist in the resulting binary. I assume there could be some small exceptions, though, like choosing to do something in a certain way so that the same approach will also work for 32-bit, and opting for another approach would perform better in 64-bit. That’s just a guess, though.
It’s mostly about maintenance load.
Btw, with PAE the host can have more than 4 GB of memory, so the limit would only apply to individual processes. Still quite feasible to use that kind of system even in the modern day–even if the browser can sometimes become quite large… And then there are of course the numerous embedded applications.
There also is no “hard limit of 4GB of RAM”. PAE was introduced nearly 30 years ago. And the kernel supports it since 1999 (version 2.3.23). You’re still limited of 4 GiB per process, though.
So no browsers…
Sure, browsers, too. They can start one process for each tab so each website has 4 GiB of RAM.
#ifdef