LInux 3.4 Kernel Has x32 ABI Support

[phoronix]

Phoronix: LInux 3.4 Kernel Has x32 ABI Support

The pull happened last week prior to the Linux 3.4-rc1 release, but one of the other interesting changes in the Linux 3.4 kernel that hasn't been talked about much is the x32 support...

http://www.phoronix.com/vr.php?view=MTA4MzE

[allquixotic]

For memory-constrained systems, this could result in significantly better memory efficiency on x86_64 CPUs. In particular, I am interested in whether the x86 Android tablets that are planned (using Intel Atom processors) are going to take advantage of this.

Basically, you get all the advantages of the x86_64 architecture, but none of the disadvantages. The main disadvantage being, that pointers take up twice as much memory. So for pointer-heavy code (and what code isn't pointer-heavy these days), all those 64-bit integers vs. 32-bit integers start to add up. Especially if your total system memory is in the range of 512 MB - 2 GB, as is the case with mobile devices.

You could ship x86_64 Atom processors, technically capable of executing the full 64-bit ISA, and use 32-bit pointers to save memory. This sounds like a win-win.

On the desktop, this will only introduce problems. We already have an x86/x86_64 split on multi-lib Debian and Fedora systems; we use naming conventions like /usr/lib for 32-bit and /usr/lib64 for 64-bit (Red Hat distros), or /usr/lib for 64-bit and /usr/lib32 for 32-bit (Debian distros). Ubuntu is trying to lead the charge with proper multi-lib support by having /usr/lib/OMG-I-AM-AN-AWFUL-AND-REALLY-LONG-ARCHITECTURE-NAME/ directories, which would work perfectly fine on a tri-arch x86, x32, x86_64 system. But that seems really complicated. Three versions of each library? Ugh. You blow all your RAM savings just having all those versions loaded in memory.

An x32 kernel, in particular, seems like it'll be fraught with problems for the desktop. Presumably you won't be able to load x86_64 kernel modules into an x32 kernel, because of the pointer size difference; you also won't be able to load x86 kernel modules into an x32 kernel, because of the ISA differences. So if you need to depend on any code -- tainted or otherwise -- that isn't designed to compile (in the case of open source) or link (in the case of binaries) with the x32 ISA, you can't use it. You're stuck with the traditional x86 or x86_64.

So while I see enormous benefit for this on "pure" x32 embedded systems and mobile devices, I think most people with >= 4GB RAM on a desktop or full-fat laptop are probably not going to care about all the extra compatibility work they'll have to do, just to save 50 - 100 megs (optimistically) in memory overhead from x86_64. Oh, and your industrial-sized workstation apps that really do use up > 4GB RAM are still going to run OOM on x32.

[cl333r]

Article typo, it's "Ingo" Molnar, not "Igno".

[XorEaxEax]

So while I see enormous benefit for this on "pure" x32 embedded systems and mobile devices, I think most people with >= 4GB RAM on a desktop or full-fat laptop are probably not going to care about all the extra compatibility work they'll have to do, just to save 50 - 100 megs (optimistically) in memory overhead from x86_64. Oh, and your industrial-sized workstation apps that really do use up > 4GB RAM are still going to run OOM on x32.

Well, there's also the speed improvements reported (~15% iirc) due to more code fitting in the cpu caches. That said I think you are right that it probably won't make a huge impact on the Linux desktop, personally I find it interesting though and will play around with it.

[ammo42]

An x32 kernel, in particular, seems like it'll be fraught with problems for the desktop. Presumably you won't be able to load x86_64 kernel modules into an x32 kernel, because of the pointer size difference; you also won't be able to load x86 kernel modules into an x32 kernel, because of the ISA differences. So if you need to depend on any code -- tainted or otherwise -- that isn't designed to compile (in the case of open source) or link (in the case of binaries) with the x32 ISA, you can't use it. You're stuck with the traditional x86 or x86_64.

So while I see enormous benefit for this on "pure" x32 embedded systems and mobile devices, I think most people with >= 4GB RAM on a desktop or full-fat laptop are probably not going to care about all the extra compatibility work they'll have to do, just to save 50 - 100 megs (optimistically) in memory overhead from x86_64. Oh, and your industrial-sized workstation apps that really do use up > 4GB RAM are still going to run OOM on x32.

x32 runs on x86_64 kernels, there is no new architecture on the kernel side.

[Nille]

@allquixotic x32 is only in userspace. The Kernel is an "normal" x86-64 Binary.

[smorovic]

New rpm/deb nightmare incoming, but distros fortunately did have some practice with the x86/x86_64 multiarch support. Adding a third one is nothing fundamentally new.

However I'd treat this differently and provide both x32 and x64 libraries in a _single_ package (it will cost some disk space, but seriously few GB's is nothing these days). This is not possible with x86 because the separate package is required, which is also part of a x86 distro (because these are reused by x64 distro builds to add x86 support), however x32 has 1:1 hw mapping with x64 and not even a new distro build is needed.

If we use the mentioned approach, presence of x32 shared libs is guaranteed for the whole system, and distributions could then choose to build some applications as x32, because in MOST cases there is absolutely no reason to use x64 over x32 (read: Firefox could grow up to 5 gigs, but the toolbar applet not)

[stqn]

I think most people could use a full x32 system because I don’t know of any app that requires more than 1 GB of RAM… No problem then.

[AnonymousCoward]

[...] most people could [...] because I [...]

Solid reasoning.

[stqn]

Thanks for approving!