From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9164AC3600B for ; Mon, 31 Mar 2025 15:34:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6A8F8280003; Mon, 31 Mar 2025 11:34:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 63158280002; Mon, 31 Mar 2025 11:34:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4D32A280003; Mon, 31 Mar 2025 11:34:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 208D7280002 for ; Mon, 31 Mar 2025 11:34:15 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id C8976C0E0F for ; Mon, 31 Mar 2025 09:38:23 +0000 (UTC) X-FDA: 83281345686.29.3744656 Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by imf23.hostedemail.com (Postfix) with ESMTP id BF8F5140002 for ; Mon, 31 Mar 2025 09:38:21 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=EmbidCCn; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf23.hostedemail.com: domain of guoren@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=guoren@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1743413902; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=PmJaKdaVmPFCf7o40+8To1AZjk0bPdmZDivd+BpQGnU=; b=phf1rf+Ou0hoUdMN/wooVtoTd6n93H6ayaVtIHDquTFWTH2loat3b/EUBqrN7v7zjLyCk3 wvSt9UOWOrDioy0kV7wwvKczcfAdFvvybrkFiwvVbChBPVugWahyNYSLrdidfhctCJ5s+a jIDjgScqoyMOQniuHDBCU5ol2pX4SyI= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=EmbidCCn; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf23.hostedemail.com: domain of guoren@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=guoren@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1743413902; a=rsa-sha256; cv=none; b=Jtxm+5YjlKlArY5LU42xkK+Rair9fCjo8hdkOHxvgHA0mJMQRGZ6Qz8ZjtTrWuq7XUCDlX 3grb/51QelccRzjZ0z81NzZe6ZrQHskeIKSlHGK9FnZrKusZRoX918FisL9a7WdyrwgoqP JXiQwcOZzwaxLkQWuT/dEx887OoL3aI= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 1E50944CB8 for ; Mon, 31 Mar 2025 09:38:20 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 505FBC4CEE5 for ; Mon, 31 Mar 2025 09:38:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1743413900; bh=c1x+Xth8BEb076RKaU7394iwjna0S1kF/5ZOoxNu0WA=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=EmbidCCnPg2evR1Jm/e6D9np4maPhvacimBkdx4K5nn8lyEYlxD1pwCOwE+lsXKRD Y8BrLZJwSAg1mhwvsaEzl7XXAbLrvvMMGLqKlB/56ICZfp3EJenKEUvhpZYt0PZrn/ hsGKR0ush6KRKl5hJaIBcHpcdSsB/Y5HM50Zmv82PZhIcDMCcfUvWZzzVjDuJ5ijoj yGGGeAI8mDfbnmsZCQaF7AlKko74dzoFU/8N/4/IB+VT6zWtqkysGzAzgSCOu31zod Ux165+eNVR3Ctq2ykDB7oH5k1GqAru0LVgJaGJKpRObsheANiNfq3c5QmducAtHZFw qQUP7Y0XoUQrA== Received: by mail-wm1-f44.google.com with SMTP id 5b1f17b1804b1-43948021a45so42926225e9.1 for ; Mon, 31 Mar 2025 02:38:20 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCX18Q5vz/1qgTjgeF6gyd1cfStV4mSoIFPWNSpH3Dcr0MBN6ZcP1L8NYcqreJx5zLr0LXpqrZCx9w==@kvack.org X-Gm-Message-State: AOJu0Yy/rHsNFIWJYfQAs7S+jCiqX04t+6rK12I7sLxijJI7w/dSQ5zq CA11Bk7exHiN6Eyu1P/z+y48pPCO3SSgjQKKhNCVr34pL0Vxpo5nQnlohzqN0h6YQBCNPnYnMih lpRVLnaKtHzDS7FYI0+zoH6bXHDg= X-Google-Smtp-Source: AGHT+IEmTy9t3wqszNWmhKwXFvTSwKGyO2WmS40zI6JyxjcYKGNkjBA/40nOrfwrIG01dOz60hryEgSrT2m9Idm+JoY= X-Received: by 2002:a05:600c:1d22:b0:43c:eeee:b713 with SMTP id 5b1f17b1804b1-43db62b82famr54290405e9.20.1743413898622; Mon, 31 Mar 2025 02:38:18 -0700 (PDT) MIME-Version: 1.0 References: <20250325121624.523258-1-guoren@kernel.org> <20250327210625.7a3021d0@pumpkin> In-Reply-To: <20250327210625.7a3021d0@pumpkin> From: Guo Ren Date: Mon, 31 Mar 2025 17:38:06 +0800 X-Gmail-Original-Message-ID: X-Gm-Features: AQ5f1JqajJWWNZSmBUwSqaUxwIkDKL0nYnERN29r5VaSm2IqpCbcgZbn7igzVag Message-ID: Subject: Re: [RFC PATCH V3 00/43] rv64ilp32_abi: Build CONFIG_64BIT kernel-self with ILP32 ABI To: David Laight Cc: arnd@arndb.de, gregkh@linuxfoundation.org, torvalds@linux-foundation.org, paul.walmsley@sifive.com, palmer@dabbelt.com, anup@brainfault.org, atishp@atishpatra.org, oleg@redhat.com, kees@kernel.org, tglx@linutronix.de, will@kernel.org, mark.rutland@arm.com, brauner@kernel.org, akpm@linux-foundation.org, rostedt@goodmis.org, edumazet@google.com, unicorn_wang@outlook.com, inochiama@outlook.com, gaohan@iscas.ac.cn, shihua@iscas.ac.cn, jiawei@iscas.ac.cn, wuwei2016@iscas.ac.cn, drew@pdp7.com, prabhakar.mahadev-lad.rj@bp.renesas.com, ctsai390@andestech.com, wefu@redhat.com, kuba@kernel.org, pabeni@redhat.com, josef@toxicpanda.com, dsterba@suse.com, mingo@redhat.com, peterz@infradead.org, boqun.feng@gmail.com, xiao.w.wang@intel.com, qingfang.deng@siflower.com.cn, leobras@redhat.com, jszhang@kernel.org, conor.dooley@microchip.com, samuel.holland@sifive.com, yongxuan.wang@sifive.com, luxu.kernel@bytedance.com, david@redhat.com, ruanjinjie@huawei.com, cuiyunhui@bytedance.com, wangkefeng.wang@huawei.com, qiaozhe@iscas.ac.cn, ardb@kernel.org, ast@kernel.org, linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org, kvm@vger.kernel.org, kvm-riscv@lists.infradead.org, linux-mm@kvack.org, linux-crypto@vger.kernel.org, bpf@vger.kernel.org, linux-input@vger.kernel.org, linux-perf-users@vger.kernel.org, linux-serial@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, maple-tree@lists.infradead.org, linux-trace-kernel@vger.kernel.org, netdev@vger.kernel.org, linux-atm-general@lists.sourceforge.net, linux-btrfs@vger.kernel.org, netfilter-devel@vger.kernel.org, coreteam@netfilter.org, linux-nfs@vger.kernel.org, linux-sctp@vger.kernel.org, linux-usb@vger.kernel.org, linux-media@vger.kernel.org Content-Type: multipart/alternative; boundary="0000000000001fc6ef0631a02e8e" X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: BF8F5140002 X-Stat-Signature: dj9p7xkharifz1yz66csp3xgs18ou18i X-Rspam-User: X-HE-Tag: 1743413901-411619 X-HE-Meta: U2FsdGVkX1/niD/B/GzaeJOyAeaGiXqKWx9s4edqAeqtaIfiFhEaAgxDseu3ZugaeMWjLlOMFkeIvrbxtyhbno0wIiQsXJ52pS72wQn7C3ov+CKKGFVDAyV+zSicXGwj6LFj10YLOUjlyZ/hJfv+r93zDe08lhKIxoEd6IvDy1F5Hr8pjjDVSsXh/OifF7Ndvuo2coGZzVicPa/5Wu5vTbdeXVQr/27lPfQq0j7RrkGzux0e9/jaMtELx/2iNiQiZ3VKOLx2jmpnysuZqMXilXvPH2+aKU4xIaL7D6tQjhs72MyCsxKUnBDS6a+Zft3C2jPkcOwHFU7G7opFHUfGMks22cKYaCBCRGJERsfQUTktae1p7QpT+L1DPxEeEQEHwEtaavwAv0Uj8Yi7wTr2qcxNp8IQ11iTXaB5KXdSEipv1N/yDZGL8TQvfAy259npy0LJGpgCCrW95NiqH7XsH6lwfPbGJfwp93S3aKuOVhRk50vlk+xBRbgBj+7JEmn6Pe4nhg+CCoxIU0IdnbMLyXp2nrGnYjsc4QaanEHk3trCVzh7f0qAev8r8rzdHI9QrqPi4h5Eg5Z89kCgUapY0F5qvBYcdpGxEyS7fxCo/qxMlqYEXrCZEpWuwZpjJHKcSlOkSFLVsChq8YbeGPl2mfS3i04Fa3dW9RKMW5Nn8+maWvtuWUpcDdGhnthk8F1YUMbw+yy+9YniVjNZ8Ny9KFamlQ8tXdp1q5roDkJKtfioIXC6Q8d4Qw9dBFoUqJtJ4AaFn4j32OJZfYwiFvcbmiaV7YhQCgMV/jQhonXEZKYr/KBYQGHzGEKHBYtLnpnZR3MQIIgw0sa4oBc4IId4wI2cc6c1n7P2/AueBmtpwZ2kpdBs5/+BLUSWMOVsffbNNk3Voaj29Vk3mJlFH2Fls+BcUmo7U3zluCRG3DiXyp2KNqZsqFfEXVrwCYSnruNzk+NmBWyuI3+pCMDJWkh Z3l+eW4M g1cRcAmYPiSBY1et3fmOxDGwkcq0zD5sxZBjVDOzs4DukIVivXVUbAfiizEqHwAbi+MdquI0pwEoEYyGUyVJi+q8RjIbwy5GmuisTqBJiH6o5dcBcQ+G9wnwFWfhP7SzCDlExcTgimfjLG+H8yT9oSc8OjHcJjOZquoVx0IjEqaf1J3APn7Cq8vhZNkl1n1+F8Ib4ye+zSd4ZgTx29Uirfy6UreBEwO9MMbuiylrmI4ZMOyEUJ+4rIWtL/WlPZvgiAdPhnxB935WqbDs4lzc+8hRJ+NZ7/wCvCckreERbONrBcD7ghCOGBhBluKgaWPOTZh1e3q9iVEwmElNlp9LnDsjelaQXRzIH6RgIqCWSlQQUZBl7qUJdkWax0kOlvIRh8cqyC2HPcKN+beZpbX1sydIhVtA/cXofovgG5DD6OedmnkyPOoTZ32nIF9qVyjOzPJXpeXqW829f40ICF+cvEgQjtNKGJf/eVzY9LkQvy7ahVz1fAdvZ0jgCcRy+j2I2BRupSUD8Xjt2g4EgbiLPVp2LxhSj3UMOmBCy2rD+EcvdwRXij6dR7OB1ehuAY4utR8GRkSfUi5hQyYPQkRsRG0tD3hAiugXAwAYUFsSOFbxxUFc= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: --0000000000001fc6ef0631a02e8e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Mar 28, 2025 at 5:06=E2=80=AFAM David Laight wrote: > > On Tue, 25 Mar 2025 08:15:41 -0400 > guoren@kernel.org wrote: > > > From: "Guo Ren (Alibaba DAMO Academy)" > > > > Since 2001, the CONFIG_64BIT kernel has been built with the LP64 ABI, > > but this patchset allows the CONFIG_64BIT kernel to use an ILP32 ABI > > for construction to reduce cache & memory footprint (Compared to > > kernel-lp64-abi, kernel-rv64ilp32-abi decreased the used memory by > > about 20%, as shown in "free -h" in the following demo.) > ... > > Why on earth would you want to run a 64bit application on a 32bit kernel. > IIRC the main justification for 64bit was to get a larger address space. Because the below chips have built the Linux ecosystem with LP64-ABI: - allwinner/sun20i-d1-lichee (128MB~1GB) - allwinner/sun20i-d1s-mangopi (64MB) - bouffalo/bl808 (64MB) - canaan/k230 (512MB) - canaan/k230d (128MB) - renesas/rzfive-smarc (256MB~1GB DDR) - sophgo/cv1800b (64MB DDR) - sophgo/cv1812h (256MB DDR) - sophgo/sg2002 (64/256MB DDR) - https://docs.banana-pi.org/en/BPI-RV2/BananaPi_BPI-RV2 (512MB DDR) By swapping the rv64ilp32-abi Linux kernel, we could immediately reduce the 5~10% memory footprint without modifying the bootloader, firmware, or rootfs binaries. The userspace ilp32-abi porting requires substantial effort, and customers want the porting step by step. > > Now you might want to compile a 32bit (ILP32) system that actually > runs in 64bit mode (c/f x32) so that 64bit maths (long long) is > more efficient - but that is a different issue. We don't introduce any x32 userspace ABI here, only for the kernel self. > (I suspect you'd need to change the process switch code to save > all 64bits of the registers - but maybe not much else??) Indeed, the pt_regs & context regs are the same as CONFIG_64BIT (64-bit width). Best Regards Guo Ren --0000000000001fc6ef0631a02e8e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Mar 28, 2025 at 5:06=E2=80=AFAM David Laig= ht <david.laight.linux@g= mail.com> wrote:
>
> On Tue, 25 Mar 2025 08:15:41 -0400<= br>> guoren@kernel.org wrote:>
> > From: "Guo Ren (Alibaba DAMO Academy)" <guoren@kernel.org>
> >> > Since 2001, the CONFIG_64BIT kernel has been built with the LP6= 4 ABI,
> > but this patchset allows the CONFIG_64BIT kernel to use= an ILP32 ABI
> > for construction to reduce cache & memory fo= otprint (Compared to
> > kernel-lp64-abi, kernel-rv64ilp32-abi dec= reased the used memory by
> > about 20%, as shown in "free -h= " in the following demo.)
> ...
>
> Why on earth wou= ld you want to run a 64bit application on a 32bit kernel.
> IIRC the = main justification for 64bit was to get a larger address space.

Beca= use the below chips have built the Linux ecosystem with LP64-ABI:
=C2=A0= - allwinner/sun20i-d1-lichee (128MB~1GB)
=C2=A0- allwinner/sun20i-d1s-ma= ngopi (64MB)
=C2=A0- bouffalo/bl808 (64MB)
=C2=A0- canaan/k230 (512MB= )
=C2=A0- canaan/k230d (128MB)
=C2=A0- renesas/rzfive-smarc (256MB~1G= B DDR)
=C2=A0- sophgo/cv1800b (64MB DDR)
=C2=A0- sophgo/cv1812h (256M= B DDR)
=C2=A0- sophgo/sg2002 (64/256MB DDR)
=C2=A0- https://docs.banana-pi.or= g/en/BPI-RV2/BananaPi_BPI-RV2 (512MB DDR)
By swapping the rv64ilp32-= abi Linux kernel, we could immediately reduce the 5~10% memory footprint wi= thout modifying the bootloader, firmware, or rootfs binaries.
The usersp= ace ilp32-abi porting requires substantial effort, and customers want the p= orting step by step.

>
> Now you might want to compile a 32= bit (ILP32) system that actually
> runs in 64bit mode (c/f x32) so th= at 64bit maths (long long) is
> more efficient - but that is a differ= ent issue.
We don't introduce any x32 userspace ABI here, only for t= he kernel self.

> (I suspect you'd need to change the process= switch code to save
> all 64bits of the registers - but maybe not mu= ch else??)
Indeed, the pt_regs & context regs are the same as CONFIG= _64BIT (64-bit width).

Best Regards
=C2=A0 =C2=A0Guo Ren
--0000000000001fc6ef0631a02e8e--