From: Arnd Bergmann <arnd@kernel.org>
To: linux-mm@kvack.org
Cc: Arnd Bergmann <arnd@arndb.de>,
Andrew Morton <akpm@linux-foundation.org>,
Andreas Larsson <andreas@gaisler.com>,
"Christophe Leroy (CS GROUP)" <chleroy@kernel.org>,
Dave Hansen <dave.hansen@linux.intel.com>,
"David Hildenbrand (Arm)" <david@kernel.org>,
Jason Gunthorpe <jgg@nvidia.com>,
Linus Walleij <linus.walleij@linaro.org>,
"Lorenzo Stoakes (ARM)" <ljs@kernel.org>,
Matthew Wilcox <willy@infradead.org>,
Malin Jonsson <malin.jonsson@est.tech>,
Richard Weinberger <richard@nod.at>,
Russell King <linux@armlinux.org.uk>,
linux-arm-kernel@lists.infradead.org,
linux-fsdevel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
x86@kernel.org
Subject: [PATCH v2 0/6] mm: highmem cleanups
Date: Thu, 12 Nov 2026 12:25:22 +0100 [thread overview]
Message-ID: <20261112112528.1116405-1-arnd@kernel.org> (raw)
From: Arnd Bergmann <arnd@arndb.de>
This is an updated series from what I posted last year [1], sorry for
taking way longer with this than I had planned. Linus brought it up today,
which triggered me to rebase the earlier patches and post it again.
At LPC 2025 [3], we got rough consensus on the plan to keep the
funcationality present for the time being but instead reduce the scope
of highmem in the kernel as much as we can without hurting users.
The short summary is a three stage process:
1. Nudge users towards using a larger lowmem zone with the
CONFIG_VMSPLIT_* options if at all possible.
2. Drop most __GFP_HIGHMEM allocations and corresponding kmap()
calls from the kernel, leaving only the subset that is likely
to contain the majority of the actual allocations.
Specifically we will keep anonymous and regular file backed
user mappings, zsmalloc, and huge pages.
3. In a few years, also drop the page cache allocations and leave
perhaps only zsmalloc using a much simpler interface. I suggested
five years as the time until we do this, but the timing depends a
lot on how the first two stages work out in practice, and how long
the remaining highmem users plan to keep updating their kernels.
This series implements stage 1, mostly using Kconfig changes to the
default settings but leaving the traditional behavior as a CONFIG_EXPERT
choice in Kconfig. With the new defaults, most installations that use
highmem today with 1 GiB or 2 GiB of system RAM will see all of their
RAM in the lowmem zone after upgrading their kernels. My estimate is
that instead of 80% to 90% of maintained embedded 32-bit systems, this
should cover over 98%.
As I don't actually have hardware in the category that still needs
highmem, I tested this using a qemu-system for Armv7 and PPC6xx running a
Debian userland with all combinations of VMSPLIT and HIGHMEM options. I
ran some kernel builds on the Arm guest to ensure that the new options
don't cause functional or performance regressions for regular workloads
that don't exceed the virtual address space. I also ran some tests
with Firefox and was positively surprised to see that this still works
on the VMSPLIT_2G_OPT configuration without highmem, though it gets
close to both the address space and lowmem size limits.
As I had to change the powerpc version a bit for the rebase, this
current version is entirely untested, but I hope that Richard and
Christophe are able to help out there, as they both understand this
code better than I do.
The change to use VMSPLIT_3G_OPT by default on Armv5 means that I could
include a patch to no longer support highmem at all on VIVT caches,
as suggested by Jason Gunthorpe. I also included the patch to drop
HIGHPTE support now, as suggested by David Hildenbrand.
The patches from this series are available in [4] for testing.
Arnd
[1] https://lore.kernel.org/all/20251219161559.556737-1-arnd@kernel.org/
[2] https://lore.kernel.org/all/CAHk-=wjPY=kfgnmtx4COEQjD5UzKx9m2-=KLGAZP4d=RKEH+pg@mail.gmail.com/
[3] https://lwn.net/Articles/1051010/
[4] https://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git/log/?h=highmem-7.4
Arnd Bergmann (5):
ARM: remove support for highmem on VIVT
mm: remove ARCH_NEEDS_KMAP_HIGH_GET
ARM: drop CONFIG_HIGHPTE support
mm: drop HIGHPTE support altogether
arch/*: increase lowmem size to avoid highmem use
arch/arm/Kconfig | 17 ++--
arch/arm/configs/aspeed_g5_defconfig | 1 -
arch/arm/configs/gemini_defconfig | 1 -
arch/arm/configs/multi_v5_defconfig | 1 -
arch/arm/configs/mvebu_v5_defconfig | 1 -
arch/arm/configs/u8500_defconfig | 1 -
arch/arm/configs/vt8500_v6_v7_defconfig | 2 -
arch/arm/include/asm/highmem.h | 56 +-------------
arch/arm/include/asm/pgalloc.h | 8 +-
arch/arm/mach-omap2/Kconfig | 1 -
arch/arm/mm/cache-feroceon-l2.c | 31 +-------
arch/arm/mm/cache-xsc3l2.c | 47 ++---------
arch/arm/mm/dma-mapping.c | 12 +--
arch/arm/mm/flush.c | 19 +----
arch/microblaze/Kconfig | 9 ++-
arch/microblaze/configs/mmu_defconfig | 1 -
arch/powerpc/Kconfig | 14 ++--
arch/powerpc/configs/44x/akebono_defconfig | 1 -
arch/powerpc/configs/85xx/ksi8560_defconfig | 1 -
arch/powerpc/configs/85xx/stx_gp3_defconfig | 1 -
arch/x86/Kconfig | 4 +-
include/linux/hugetlb.h | 5 +-
include/linux/mm.h | 1 -
include/linux/pgtable.h | 9 ---
mm/highmem.c | 86 +++------------------
25 files changed, 50 insertions(+), 280 deletions(-)
--
2.53.0
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andreas Larsson <andreas@gaisler.com>
Cc: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: David Hildenbrand (Arm) <david@kernel.org>
Cc: Jason Gunthorpe <jgg@nvidia.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Lorenzo Stoakes (ARM) <ljs@kernel.org>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Malin Jonsson <malin.jonsson@est.tech>
Cc: Richard Weinberger <richard@nod.at>
Cc: Russell King <linux@armlinux.org.uk>
Cc: linux-mm@kvack.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-fsdevel@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: x86@kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
next reply other threads:[~2026-11-12 11:25 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-12 11:25 Arnd Bergmann [this message]
2026-11-12 11:25 ` [PATCH v2 1/6] ARM: remove support for highmem on VIVT Arnd Bergmann
2026-11-12 11:25 ` [PATCH v2 2/6] mm: remove ARCH_NEEDS_KMAP_HIGH_GET Arnd Bergmann
2026-11-12 11:48 ` Mike Rapoport
2026-11-12 11:25 ` [PATCH v2 3/6] ARM: drop CONFIG_HIGHPTE support Arnd Bergmann
2026-11-12 11:47 ` Mike Rapoport
2026-11-12 12:22 ` Arnd Bergmann
2026-11-12 11:25 ` [PATCH v2 4/6] mm: drop HIGHPTE support altogether Arnd Bergmann
2026-11-12 11:54 ` Mike Rapoport
2026-11-12 12:33 ` David Hildenbrand (Arm)
2026-11-12 13:26 ` Arnd Bergmann
2026-11-12 11:25 ` [PATCH v2 5/6] arch/*: increase lowmem size to avoid highmem use Arnd Bergmann
2026-11-12 12:00 ` Mike Rapoport
2026-11-12 11:25 ` [PATCH v2 6/6] ARM: add CONFIG_VMSPLIT_2G_OPT option Arnd Bergmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261112112528.1116405-1-arnd@kernel.org \
--to=arnd@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=andreas@gaisler.com \
--cc=arnd@arndb.de \
--cc=chleroy@kernel.org \
--cc=dave.hansen@linux.intel.com \
--cc=david@kernel.org \
--cc=jgg@nvidia.com \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux@armlinux.org.uk \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=ljs@kernel.org \
--cc=malin.jonsson@est.tech \
--cc=richard@nod.at \
--cc=willy@infradead.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox