Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp995996imu; Thu, 13 Dec 2018 07:48:43 -0800 (PST) X-Google-Smtp-Source: AFSGD/WRjdXxRaS6jbcXBaRrDXm8QGM4yxUxoJeBMKd4cH4+lfhqlC1RagBRs0oDbb1yguYmwZsN X-Received: by 2002:a63:e655:: with SMTP id p21mr21979399pgj.70.1544716123030; Thu, 13 Dec 2018 07:48:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1544716123; cv=none; d=google.com; s=arc-20160816; b=idlRMG9p0nfs6st9hZOOVENBsh3/8Fq9spF9TgFlbII5IHkaJ/Qh1rXx632LvHBTZa P3Cjl0AQOVZcagXA56tBHGMQc+XgaIvyBcPVGUE+YTQoHZkuaP3LAAkk9Y96X+bETRk9 KAu/JFiwX3gpjWdwgGzQdPybukUBuD1rjHUtf4zm8whXagrcPKAUz6o0voSz02yuZh3/ wmspClbEuRASD/nA7y5HPVKGzm0pmGzoyaT4isOcQrFr+ES1v3S0EH+MNCtYbOCgfS+d yhdGaxa/qLqaGhOnDMEYATfhM8NIl94oArZ4MZOrPvV5il1405tTxHMjo8a3CiBkQ3qn ktFw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=E6eri7DERpU5AOSLUsbXMPV0GqnePrnLSVUgtfhWszE=; b=LOK2oeu10JU1bSWx89amz9IpXLYXoKkoa6IwvjPcPY30BzSiKkBr+PKfdwLZ/ZjgEm Vae0e1su5MN4AN1SREY2+tFNDOpZzO+64IOLnwur+oWH+M/pjqfxRhlm4lq3TkUDrkb3 3hkPqRiB1I0W2JPTo63b0h0jQy5eFDqHDdQaGHbKwNrbp6HX0Q6Ke3E4ZWaOTDqZI/2A pO3g5jM7rmORrBSGOwPITVCE8AwUALFmALHd1lvzNhAPzxfzdVVGD6vANMup+KvbyIFU Gllpp6RTE5ed8TLTjUwFqPws499vEZZp0P4wAGEuSzoHwpBGeUDXOylMDaZBcegF3Mq4 of7Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b="S/KXkiOD"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p3si1658283plk.424.2018.12.13.07.48.21; Thu, 13 Dec 2018 07:48:42 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b="S/KXkiOD"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728620AbeLMPqg (ORCPT + 99 others); Thu, 13 Dec 2018 10:46:36 -0500 Received: from mail-qk1-f193.google.com ([209.85.222.193]:40912 "EHLO mail-qk1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726150AbeLMPqf (ORCPT ); Thu, 13 Dec 2018 10:46:35 -0500 Received: by mail-qk1-f193.google.com with SMTP id y16so1366232qki.7; Thu, 13 Dec 2018 07:46:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=E6eri7DERpU5AOSLUsbXMPV0GqnePrnLSVUgtfhWszE=; b=S/KXkiODv2W7QOfSUDruPhBBdCRupdFMC8ATReRcmvWAiYrZ1VYt+iU8BFcBSs4pgD D1lcXDmO7v+ZnZfLm2zqCFJ57FcpTdRzrL/eIWhlULW876EVZRsoYY8fxI0pguZKjrQR LFoc7BtDNbxohgLONDOEJi17qrK8JiI7LtFjxMNLGnfpk8KbyS+QPPFonSBR/LK5zy8U aUNLt7FZ4ZHL7QPiWYJQAOkiNHNzG2E7Yx51LaWf9aKXezKDUUfBkKvH6Br43WqRPzIC n3VH8AbZjj6ZKA0Rlixqt9TfbeRS8gmBzwv4Gzcf8isapuPZD5WlhCjz7tM8jkaIFdgG RM+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=E6eri7DERpU5AOSLUsbXMPV0GqnePrnLSVUgtfhWszE=; b=bvFz2nsv1z2eqMoGsmSWGUB/QpHDbIOzKTLG52FKOI3HM4iafw31oGMyvng11lJ9ym qtbh/Yu85EuGyQpkR/WjFwLcqsdHlMxHGcOik6hdQSLbakTQvjlbO/bCySlhl0ux49qT ra/25K6pwo2r2L7Xsd3nMgNJqPwe4RXX49cTnUtKtieNwTdkw/bpgFiGuCKPYPl1/InM KBmJ/bFkTl/BhavSqd+dDPi9XAsCVZ/JF1XVNG1CxRo4bTPztz26IEKnJ+pchZk9ECjB UKX5/f0nL6C4x+46fd0UwDVLs/RVrUZJoI5+sr880jFbvpQ973t5TP04UHwlc9ae8/vE yR/w== X-Gm-Message-State: AA+aEWZYThK3zN6ZUyeu3qSQ8Es15eE8PVyiX8GmW/SjpbzBaLFW1jkL r3TvrO7w0H4ltRZqK7jcb/jWWF3v1Eh1MJkJqaU= X-Received: by 2002:a37:99c5:: with SMTP id b188mr23381956qke.100.1544715994395; Thu, 13 Dec 2018 07:46:34 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Lance Richardson Date: Thu, 13 Dec 2018 10:46:23 -0500 Message-ID: Subject: Re: Can we drop upstream Linux x32 support? To: olof@lixom.net Cc: torvalds@linux-foundation.org, luto@kernel.org, x86@kernel.org, linux-kernel@vger.kernel.org, linux-api@vger.kernel.org, hpa@zytor.com, peterz@infradead.org, bp@alien8.de, fweimer@redhat.com, vapier@gentoo.org, hjl.tools@gmail.com, dalias@libc.org, x32@buildd.debian.org, arnd@arndb.de, will.deacon@arm.com, catalin.marinas@arm.com Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Dec 13, 2018 at 9:39 AM Olof Johansson wrote: > > On Tue, Dec 11, 2018 at 9:40 AM Linus Torvalds > wrote: > > > > On Mon, Dec 10, 2018 at 5:23 PM Andy Lutomirski wrote: > > > > > > I'm seriously considering sending a patch to remove x32 support from > > > upstream Linux. Here are some problems with it: > > > > I talked to Arnd (I think - we were talking about all the crazy ABI's, > > but maybe it was with somebody else) about exactly this in Edinburgh. > > > > Apparently the main real use case is for extreme benchmarking. It's > > the only use-case where the complexity of maintaining a whole > > development environment and distro is worth it, it seems. Apparently a > > number of Spec submissions have been done with the x32 model. > > > > I'm not opposed to trying to sunset the support, but let's see who complains.. > > I'm just a single user. I do rely on it though, FWIW. > > I hadn't finished my benchmarking in Edinburgh, but for my new machine > that does kernel builds 24/7, I ended up going with x32 userspace (in > a container). > > Main reason is that it's a free ~10% improvement in runtime over > 64-bit. I.e. GCC-as-a-workload is quite a bit faster as x32, > supposedly mostly due to smaller D cache footprints (I ran out of > cycles to tinker with back and forth perf data collection and settled > down on just running it). > > Running classic 32-bit (i386? i686? whatever it's called) is about > half as good. I.e. even then I get a ~5% performance win. Less than > x32, but still better than 64-bit userspace. > > > -Olof I'm familiar with two embedded Linux systems using x32 ABI for the following reasons: - Significant performance benefits over i386 ABI. - Smaller memory footprint than x86_64 (pointer-heavy data structures) - Large legacy software base with many ILP32 assumptions, much smaller effort to move to x32 than x86_64. Some examples of (relatively minor) problems encountered with x32: - Time-related data type mismatch in socket options (fixed) https://patchwork.ozlabs.org/patch/904254/ - Userspace overrun with select() (patch proposed) https://patchwork.kernel.org/patch/10245677/ - glibc get_phys_pages() doesn't work correctly with x32 (assumes that struct sysinfo fields are not wider than "long"). So, one small vote for keeping x32 with the hope that support for it can continue to be improved... - Lance