The future of 32-bit support in the kernel

People naturally think about desktop machines first, he continued. If you were running Linux in the 1990s, you had a 32-bit, desktop system. Unix systems, though, moved to 64-bit platforms around 30 years ago, and the Linux desktop made that move about 20 years ago. Even phones and related devices have been 64-bit for the last decade. If those systems were all that Linux had to support, 32-bit support would have long since been removed from the kernel. He summarized the situation with this slide, showing how the non-embedded architectures have transitioned to either 64-bit or nonexistence over time:

The world is not all desktops — or servers — though; embedded Linux exists as well. About 90% of those systems are running on Arm processors. The kernel has accumulated a lot of devicetree files describing those systems over the years; only in this last year has the number of devicetrees for armv8 (64-bit) systems exceeded the number for armv7 (32-bit) systems.

For Arm processors with pre-armv7 architectures, there are only three for which it is still possible to buy hardware, but a number are still supported by the kernel community:

Many other pre-armv7 CPUs are out of production, but the kernel still has support for them. Of those, he said, there are about ten that could be removed now. It would be nice to be able to say that support for the others will be removed after a fixed period, ten years perhaps, but hardware support does not work that way. Instead, one has to think in terms of half lives; every so often, it becomes possible to remove support for half of the platforms. It all depends on whether there are users for the processors in question.

The kernel is still adding support for some 32-bit boards, he said, but at least ten new 64-bit boards gain support for each 32-bit one.

There are a number of non-Arm 32-bit architectures that still have support in the kernel; these include arc, microblaze, nios2, openrisc, rv32, sparc/leon, and xtensa. All of them are being replaced by RISC-V processors in new products. RISC-V is what you use if you don't care about Arm compatibility, he said.

Then, there is the dusty corner where nommu (processors without a memory-management unit) live; these include armv7-m, m68k, superh, and xtensa. Nobody is building anything with this kind of hardware now, and the only people who are working on them in any way are those who have to support existing systems. "Or to prove that it can be done."

There are still some people who need to run 32-bit applications that cannot be updated; the solution he has been pushing people toward is to run a 32-bit user space on a 64-bit kernel. This is a good solution for memory-constrained systems; switching to 32-bit halves the memory usage of the system. Since, on most systems, almost all memory is used by user space, running a 64-bit kernel has a relatively small cost. Please, he asked, do not run 32-bit kernels on 64-bit processors.

There are some definite pain points that come with maintaining 32-bit support; most of the complaints, he said, come from developers in the memory-management subsystem. The biggest problem there is the need to support high memory; it is complex, and requires support throughout the kernel. High memory is needed when the kernel lacks the address space to map all of the installed physical memory; that tends to be at about 800MB on 32-bit systems. (See this article for more information about high memory).

Currently the kernel is able to support 32-bit systems with up to 16GB of installed memory. Such systems are exceedingly rare, though, and support for them will be going away soon. There are a few 4GB systems out there, including some Chromebooks. Systems with 2GB are a bit more common. Even these systems, he said, are "a bit silly" since the memory costs more than the CPU does. There are some use cases for such systems, though. Most 32-bit systems now have less than 1GB of installed memory. The kernel, soon, will not try to support systems with more than 4GB.

There are some ideas out there for how to support the larger-memory 32-bit systems without needing the high-memory abstraction. Linus Walleij is working on entirely separating the kernel and user-space address spaces, giving each 4GB to work with; this is a variant on the "4G/4G" approach that has occasionally been tried for many years. It is difficult to make such a system work efficiently, so this effort may never succeed, Bergmann said.

Another approach is the proposed "densemem" memory model, which does some fancy remapping to close holes in the physical address space. Densemem can support up to 2GB and is needed to replace the SPARSEMEM memory model, the removal of which which will eventually be necessary in any case. This work has to be completed before high memory can be removed; Bergmann said that he would be interested in hearing from potential users of the densemem approach.

One other possibility is to drop high memory, but allow the extra physical memory to be used as a zram swap device. That would not be as efficient as accessing the memory directly, but it is relatively simple and would make it possible to drop the complexity of high memory.

Then, there is the year-2038 problem, which he spent several years working on. The kernel-side work was finished in 2020; the musl C library was updated that same year, and the GNU C Library followed the year after. Some distributors have been faster than others to incorporate this work; Debian and Ubuntu have only become year-2038-safe this year.

The year-2038 problem is not yet completely solved, though; there are a lot of packages that have unfixed bugs in this area. Anything using futex(), he said, has about a 50% chance of getting time handling right. The legacy 32-bit system calls, which are not year-2038 safe, are still enabled in the kernel, but they will go away at some point, exposing more bugs. There are languages, including Python and Rust, that have a lot of broken language bindings. Overall, he said, he does not expect any 32-bit desktop system to survive the year-2038 apocalypse.

A related problem is big-endian support, which is also 32-bit only, and also obsolete. Its removal is blocked because IBM is still supporting big-endian mainframe and PowerPC systems; as long as that support continues, big-endian support will stay in the kernel.

A number of other types of support are under discussion. There were once 32-bit systems with more than eight CPUs, but nobody is using those machines anymore, so support could be removed. Support for armv4 processors, such as the DEC StrongARM CPU, should be removed. Support for early armv6 CPUs, including the omap2 and i.mx31, "complicates everything"; he would like to remove it, even though there are still some Nokia 770 systems in the wild. The time is coming for the removal of all non-devicetree board files. Removal of support for Cortex M CPUs, which are nommu systems, is coming in a couple of years. Developers are eyeing i486 CPU support, but that will not come out yet. Bergmann has sent patches to remove support for KVM on 32-bit CPUs, but there is still "one PowerPC user", so that support will be kept for now.

To summarize, he said, the kernel will have to retain support for armv7 systems for at least another ten years. Boards are still being produced with these CPUs, so even ten years may be optimistic for removal. Everything else, he said, will probably fade away sooner than that. The removal of high-memory support has been penciled in for sometime around 2027, and nommu support around 2028. There will, naturally, need to be more discussion before these removals can happen.

An audience member asked how developers know whether a processor is still in use or not; Bergmann acknowledged that it can be a hard question. For x86 support, he looked at a lot of old web pages to make a list of which systems existed, then showed that each of those systems was already broken in current kernels for other reasons; the lack of complaints showed that there were no users. For others, it is necessary to dig through the Git history, see what kinds of changes are being made, and ask the developers who have worked on the code; they are the ones who will know who is using that support.

Another person asked about whether the kernel would support big-endian RISC-V systems. Bergmann answered that those systems are not supported now, and he hoped that it would stay that way. "With RISC-V, anybody can do anything, so they do, but it is not always a good idea". The final question was about support for nommu esp32 CPUs; he answered that patches for those CPUs exist, but have not been sent upstream. Those processors are "a cool toy", but he does not see any practical application for them.

The slides for this talk are available. The curious may also want to look at Bergmann's 2020 take on this topic.

[Thanks to the Linux Foundation, LWN's travel sponsor, for supporting my travel to this event.]