[PATCH 1/4] arch/*: increase lowmem size to avoid highmem use

[Christophe Leroy (CS GROUP)]

Le 19/12/2025 à 17:15, Arnd Bergmann a écrit :
> From: Arnd Bergmann <arnd at arndb.de>
> 
> 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 <linux at armlinux.org.uk>
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: Thomas Gleixner <tglx at linutronix.de>
> Cc: Ingo Molnar <mingo at redhat.com>
> Cc: Borislav Petkov <bp at alien8.de>
> Cc: Dave Hansen <dave.hansen at linux.intel.com>
> Cc: x86 at kernel.org
> Cc: "H. Peter Anvin" <hpa at zytor.com>
> Cc: Madhavan Srinivasan <maddy at linux.ibm.com>
> Cc: Michael Ellerman <mpe at ellerman.id.au>
> Cc: Nicholas Piggin <npiggin at gmail.com>
> Cc: Christophe Leroy (CS GROUP) <chleroy at kernel.org>
> Cc: linuxppc-dev at lists.ozlabs.org
> Cc: Michal Simek <monstr at monstr.eu>
> Cc: Andrew Morton <akpm at linux-foundation.org>
> Cc: David Hildenbrand <david at kernel.org>
> Cc: Lorenzo Stoakes <lorenzo.stoakes at oracle.com>
> Cc: Liam R. Howlett <Liam.Howlett at oracle.com>
> Cc: Vlastimil Babka <vbabka at suse.cz>
> Cc: Mike Rapoport <rppt at kernel.org>
> Cc: Suren Baghdasaryan <surenb at google.com>
> Cc: Michal Hocko <mhocko at suse.com>
> Cc: Matthew Wilcox <willy at infradead.org>
> Cc: linux-mm at kvack.org
> Cc: Richard Weinberger <richard at nod.at>
> Cc: Linus Walleij <linus.walleij at linaro.org>
> Cc: Nishanth Menon <nm at ti.com>
> Cc: Andreas Larsson <andreas at gaisler.com>
> Cc: Lucas Stach <l.stach at pengutronix.de>
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> ---
>   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) <chleroy at kernel.org>

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