Re: Can we drop upstream Linux x32 support?

[Rich Felker]

On Wed, Dec 12, 2018 at 02:46:00PM +0000, Steven Newbury wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On Wed, 2018-12-12 at 09:01 -0500, Rich Felker wrote:
> > On Wed, Dec 12, 2018 at 09:12:34AM +0000, Steven Newbury wrote:
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA256
> > > 
> > > First off I'd like to request: Please don't break my userspace!
> > > 
> > > I have a number of systems running with x32-abi as native.  They
> > > work
> > > well, I've no want or desire to upgrade their memory or CPUs to
> > > make
> > > keep them working as well as they do now.  Let alone the hassle of
> > > having to redeploy with a completely different ABI.
> > > 
> > > 
> > > I've been working on getting as much userspace as I can working
> > > with
> > > x32 since it first became somewhat usable, I've sent patches
> > > upstream
> > > and pushed to encourage projects to write portable code.  Sometimes
> > > that has meant just little tweaks to build systems, or sometimes
> > > disabling asm where I consider it isn't worth the effort of making
> > > it
> > > work.  For other projects I've converted the asm or even in some
> > > cases
> > > got the JIT working, mozjs17 for example.
> > > 
> > > So I'm both a user and a developer.
> > > 
> > > Breaking support for x32 would be really bad for me, but if I'm the
> > > only one using it I suppose I can't really justify it being kept on
> > > that basis.  I know CERN has sucessfully experimented with it over
> > > the
> > > years though, so I wouldn't be surprised if there are other users
> > > hiding out there.
> > > 
> > > I can't help but wonder if it wouldn't make more sense to drop x86
> > > support from long mode than x32.  AMD64 x86 support was always
> > > intended
> > >  as a compatibility feature, I very much doubt there are more
> > > people
> > > out there using an x86 native userspace on a 64 bit kernel than
> > > there
> > 
> > I am. The only reason I'm using a 64-bit kernel with it is to get the
> > full 4GB address space for userspace rather than just 3GB. I suspect
> > there are more users like me than like you.
> > 
> You may well be right, I lack any data either way.  I just find it hard
> to believe I'm, what, one of two users of x32?
> 
> > Unlike x32, i386 is actually widely supported and works, and achieves
> > most of the benefits of x32, but with marginally worse performance
> > due
> x32 works, and is widely supported by the fact that the vast majority
> of free software is just a compile away.  Now, there are holes, I've
> been trying to get Chromium/qtwebengine ported for the last couple of
> weeks.
> 
> The performance isn't marginally worse, it's much worse, unless the
> code in question is hand optimized SIMD or is otherwise not really
> standard "IA32 ISA" anyway.

When the baseline improvement is roughly 2x (because you can double N
in make -jN), I consider 10-20% "marginal". Obviously there's a
perspective where 10-20% is huge. Have you actually observed x32 gcc
(since gcc is the example I'm using here, where it makes a big
difference) running that much faster than i386 gcc, though?

What I meant by "widely supported" is that pretty much any kernel
that's shipped can run i386 binaries. On the other hand, at least as I
understand it,lots of distros have x32 disabled because it's "not
used" or because there were a couple historic vulns exposed by having
it enabled and they just decided it wasn't worth it.

> > performance sensitive it's the right choice for shipping static
> > binaries, especially if they may be memory-hungry, since it works on
> > pretty much any box.
> > 
> When it comes to power usage and latency any code that runs often is
> peformance senstitive.  I can't argue about shipping i386 static
> binaries, they'll work on pretty much any *x86* box, I agree.

OK, so we're on the same page there.

> > > are native x32 users.  x86 support could be implemented via KVM
> > > and/or
> > > qemu-user.  There is no reason to keep the extra complexity in the
> > > kernel for what is effectively an emulation layer anyway.
> > 
> > qemu-user is a non-solution. Not only does it result in being much
> > slower and using more resources than just running a 64-bit userspace
> > (defeating the purpose); it's also incapable of correctly emulating
> > lots of corner cases. I've never been able to get it to work with
> > thread cancellation, and doing so is fundamentally hard because it
> > would require heavy emulation of signals rather than passing them
> > through.
> > 
> What's the purpose?  Running IA32 binaries is for legacy.  You don't
> run i386/IA32 binaries for the performance.  You use i386 as x32 was
> intended, that's succifient for you.  Great.  I get the benefits I want
> from an x32 userspace with amd64 binaries and libraries where it makes
> sense as I understand does Thorsten.  Are you saying this wrong,
> broken(?), and should be removed?

No, I'm not really taking a position here except that i386 (IA32)
should not be removed. I agree that x32 is useful (which a lot of
people are wrongly dismissing), but I also agree that the kernel code
for it is a mess and a maintenance burden, and I'm not sure if the
usefulness justifies that burden. I think it's really helpful to hear
from people like you who are using it why you care that it's there.

Rich