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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id D59E1E74916 for ; Wed, 24 Dec 2025 11:35:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:In-Reply-To:From:References:Cc:To:Subject:MIME-Version:Date: Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=aPfIf24VliWQq0f8Kj4Kw8bFV8BRu0VC6Nhx23FKLvY=; b=RRvYkYFxlZ96Mp7ne9RCzb1T+M S93621ZuSIl++TE3Ie30UAvyqHBkpMvSmSNX/J9UnIxSksNHw9FhZwrTs0323I6ASdx2m6YhvzoTz pZnW0Ea7evq6PoPVtIkycfhoTViKywcY1s7w8CvWx0fW4+8hKjoXpJ7A6RgNYVDW378xWrHtZq5EZ Tf8k01tSaJHyZu1yvZa9PdQSIyAHgnMgelu+bsADPUFhTXbEjiGeEHaSB4OlQVDfnhwQDx+Co5suf OhntoeIMV9OrmCAcz+cnRGVyRCqonKhZ6RnSjBvl9Nmy8M3nlcWjNCWJZoFW3Ytqum0YFhp1ksymh LxFmoOjQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1vYN9c-0000000GkZ6-14Oj; Wed, 24 Dec 2025 11:35:44 +0000 Received: from tor.source.kernel.org ([2600:3c04:e001:324:0:1991:8:25]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1vYN9b-0000000GkYy-1viw for linux-arm-kernel@lists.infradead.org; Wed, 24 Dec 2025 11:35:43 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 5CEE260010; Wed, 24 Dec 2025 11:35:42 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0A511C4CEFB; Wed, 24 Dec 2025 11:35:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1766576142; bh=rcZ3nMY4d65lf7YZ3P3xmWEvn3BCIy1Hqxm5btFypgE=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=Xyh3uCiqBwLSFzvpXcwS7OgzIHuc0bPj2+++1C+l1eEdHzwH9vJxSkiPqkRFMbS1y ps9iufDkUHMFc+Ubsp/Ih+8vg/xG8gALVWWcXY8qNStsjwnxrLOqaekU8um42jJEfS Lc4m/ukrr2IIbJASAXqg+HHenooEDls2rLMRH+jytjJ6hh1g6L3+GcX8wqn7OZWMYC HKN4ffk7wlUSVmn8o1KLxUx+Ck8RnJ4pswDZfnYqLfRA9T9YiYmihb5Eh3YYjWHQxH H4dgYwbOm0YyQODKZahb3AHHHOWVb79bXnGIvQqAB1Qib22CmyKuAdU37Gl3WgD+CW 8Arj0xFK1ZM8A== Message-ID: <6089e76b-80aa-4254-af70-12b96d115a2e@kernel.org> Date: Wed, 24 Dec 2025 12:35:31 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/4] arch/*: increase lowmem size to avoid highmem use To: Arnd Bergmann , linux-mm@kvack.org Cc: Arnd Bergmann , Andrew Morton , Andreas Larsson , Dave Hansen , Jason Gunthorpe , Linus Walleij , Matthew Wilcox , Richard Weinberger , Russell King , linux-arm-kernel@lists.infradead.org, linux-fsdevel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, x86@kernel.org, Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , Madhavan Srinivasan , Michael Ellerman , Nicholas Piggin , Michal Simek , David Hildenbrand , Lorenzo Stoakes , "Liam R . Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Nishanth Menon , Lucas Stach References: <20251219161559.556737-1-arnd@kernel.org> <20251219161559.556737-2-arnd@kernel.org> Content-Language: fr-FR From: "Christophe Leroy (CS GROUP)" In-Reply-To: <20251219161559.556737-2-arnd@kernel.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Le 19/12/2025 à 17:15, Arnd Bergmann a écrit : > From: Arnd Bergmann > > Most of the common 32-bit architectures (x86, arm, powerpc) all use the > default virtual memory layout that was already in place for i386 systems > in the 1990s, using exactly 3GiB of user TASK_SIZE, with the upper 1GiB > of addresses split between (at most 896MiB) lowmem and vmalloc. > > Linux-2.3 introduced CONFIG_HIGHMEM for large x86 server machines that > had 4GiB of RAM or more, with the VMSPLIT_3G/2G/1G options added in > v2.6.16 for machines that had one or two gigabytes of memory but wanted > to avoid the overhead from managing highmem. Over time, similar options > appeared on other 32-bit architectures. > > Twenty years later, it makes sense to reconsider the default settings, > as the tradeoffs have changed a bit: > > - Configurations with more than 2GiB have become extremely rare, > as any users with large memory have moved on to 64-bit systems. > There were only ever a few Laptop models in this category: Apple > Powerbook G4 (2005), Macbook (2006), IBM Thinkpad X60 (2006), Arm > Chromebooks based on Exynos 5800 (2014), Tegra K1 (2014) and RK3288 > (2015), and manufacturer support for all of these has ended in 2020 > or (much) earlier. > Embedded systems with more than 2GiB use additional SoCs of a > similar vintage: Intel Atom Z5xx (2008), Freescale QorIQ (2008), > Marvell Armada XP (2010), Freescale i.MX6Q (2011), LSI Axxia (2013), > TI Keystone2 (2014), Renesas RZ/G1M (2015). Most boards based on > these have stopped receiving kernel upgrades. Newer 32-bit chips > only support smaller memory configurations, though in particular the > i.MX6Q and Keystone2 families have expected support cycles past 2035. > While 32-bit server installations used to support even larger memory, > none of those seem to still be used in production on any architecture. > > - While general-purpose distributes for 32-bit targets were common, > it was rather risky to change the CONFIG_VMSPLIT setting because > there is always a possibility of running into device driver bugs or > applications that need a large virtual memory size. Presumably > a lot of these issues have been resolved now, so most setups should > be fine using a custom vmsplit instead of highmem now. > > - As fewer users test highmem, the expectation is that it will > increasingly break in the future, so getting users to change the > vmsplit means that even if there is a bug to fix initially, > it improves the situation in the long run. > > - Highmem will ultimately need to be removed, at least for the page > cache and most other code using it today. In a previous discussion, I > had suggested doing this as early as 2029, but based on the discussions > since ELC, the plan is now to leave highmem-enabled page cache as an > option until at least 2029, at which point remaining users will have > the choice between no longer updating kernels or using a combination of > a custom vmsplit and zram/zswap. Changing the defaults now should both > speed up the highmem deprecation and make it less painful for users. > > - The most VM space intensive applications tend to be web browsers, > specifcally Chrome/ChromeOS and Firefox. Both have now stopped > providing binary updates, but Firefox can still be built from source. > Testing various combinations on Debian/armhf, I found that Firefox 140 > can still show complex websites with VMSPLIT_2G_OPT with and without > HIGHMEM, though it failed for me both with the small address space > of VMSPLIT_1G and the small lowmem of VMSPLIT_3G_OPT when HIGHMEM > is disabled. > This is likely to get worse with future versions, so embedded users > may still be forced to migrate to specialized browsers like WPE Webkit > when HIGHMEM pagecache is finally removed. > > Based on the above observations and the discussion at the kernel summit, > change the defaults to the most appropriate values: use 1GiB of lowmem on > non-highmem configurations, and either 2GiB or 1.75GiB of lowmem on highmem > builds, depending on what is available on the architecture. As ARM_LPAE > and X86_PAE builds both require a gigabyte-aligned vmsplit, those get > to use VMSPLIT_2G. The result is that the majority of previous highmem > users now only need lowmem. For platform specific defconfig files that > are known to only support up to 1GiB of RAM, drop the CONFIG_HIGHMEM line > as well as a simplification. > > On PowerPC and Microblaze, the options have somewhat different names but > should have the same effect. MIPS and Xtensa cannot support a larger > than 512MB of lowmem but are limited to small DDR2 memory in most > implementations, with MT7621 being a notable exception. ARC and C-Sky > could support a configurable vmsplit in theory, but it's not clear > if anyone still cares. > SPARC is currently limited to 192MB of lowmem and should get patched > to behave either like arm/x86 or powerpc/microblaze to support 2GiB > of lowmem. > > There are likely going to be regressions from the changed defaults, > in particular when hitting previously hidden device driver bugs > that fail to set the correct DMA mask, or from applications that > need a large virtual address space. > Ideally the in-kernel problems should all be fixable, but the previous > behavior is still selectable as a fallback with CONFIG_EXPERT=y > > Cc: Russell King > Cc: linux-arm-kernel@lists.infradead.org > Cc: Thomas Gleixner > Cc: Ingo Molnar > Cc: Borislav Petkov > Cc: Dave Hansen > Cc: x86@kernel.org > Cc: "H. Peter Anvin" > Cc: Madhavan Srinivasan > Cc: Michael Ellerman > Cc: Nicholas Piggin > Cc: Christophe Leroy (CS GROUP) > Cc: linuxppc-dev@lists.ozlabs.org > Cc: Michal Simek > Cc: Andrew Morton > Cc: David Hildenbrand > Cc: Lorenzo Stoakes > Cc: Liam R. Howlett > Cc: Vlastimil Babka > Cc: Mike Rapoport > Cc: Suren Baghdasaryan > Cc: Michal Hocko > Cc: Matthew Wilcox > Cc: linux-mm@kvack.org > Cc: Richard Weinberger > Cc: Linus Walleij > Cc: Nishanth Menon > Cc: Andreas Larsson > Cc: Lucas Stach > Signed-off-by: Arnd Bergmann > --- > arch/arm/Kconfig | 5 ++++- > arch/arm/configs/aspeed_g5_defconfig | 1 - > arch/arm/configs/dove_defconfig | 2 -- > arch/arm/configs/mv78xx0_defconfig | 2 -- > arch/arm/configs/u8500_defconfig | 1 - > arch/arm/configs/vt8500_v6_v7_defconfig | 3 --- > arch/arm/mach-omap2/Kconfig | 1 - > arch/microblaze/Kconfig | 9 ++++++--- > arch/microblaze/configs/mmu_defconfig | 1 - > arch/powerpc/Kconfig | 17 +++++++++++------ > arch/powerpc/configs/44x/akebono_defconfig | 1 - > arch/powerpc/configs/85xx/ksi8560_defconfig | 1 - > arch/powerpc/configs/85xx/stx_gp3_defconfig | 1 - Reviewed-by: Christophe Leroy (CS GROUP) Be aware that it will likely trivialy conflict with https://lore.kernel.org/linuxppc-dev/6a2575420770d075cd090b5a316730a2ffafdee4.1766574657.git.chleroy@kernel.org/ Another point is that it will increase the overall memory usage when people activate KASAN as KASAN reserves 1/8 of RAM for lowmem memory. I think we need to look at the impact on available virtual memory, because 1/8 of 2G is 256M which is the size of the last segment shared by KASAN shadow mem and vmalloc. Christophe