Re: [TECH TOPIC] Reaching consensus on CONFIG_HIGHMEM phaseout

Arnd Bergmann
2025-09-18T13:13:40Z

On Wed, Sep 17, 2025, at 14:59, Jason Gunthorpe wrote:
> On Tue, Sep 09, 2025 at 11:23:37PM +0200, Arnd Bergmann wrote:
>
>> I'm still collecting information about which of the remaining highmem
>> users plan to keep updating their kernels and for what reason.
>
> On this topic of removing some parts of highmem, can we say goodbye to
> kmap_high_get()? Only ARM uses it and only for
> !cache_is_vipt_nonaliasing() systems.

Good idea. I think we are almost there, just need to verify that
there is actually no impact for existing users. I already knew
that there is very little highmem usage on ARMv6 and earlier, but
I tried to recheck all platforms that might be affected:

* As you say (and contrary to what the code comments suggest),
all ARMv7 and most ARMv6 systems have non-aliasing VIPT or
PIPT caches, so kmap_high_get() does nothing, and we could
just turn it off for those configurations.

* ARMv6 with aliasing VIPT caches exist but are fairly rare,
and I think there are no ARMv6 machines left that actually
use highmem. AST2500 is commonly used and has aliasing
caches, but I only see machines with 512MB or less, and
its aspeed_v5_defconfig enables CONFIG_SMP (for AST2600).
OMAP2 and realview are in the same category but less
important. imx3, s3c64xx and bcm2835 are non-aliasing
(and don't have highmem either).

* VIVT caches are used on all ARMv5 and earlier, so removing
kmap_high_get() would effectively break highmem these.
Most ARMv5 use very small amounts of memory (<256M) in
a single physical address range, so they are unaffected,
we just have to go through the ones that are left.

* Intel IOP (armv5 xscale) certainly had highmem but was
removed a while ago.

* Marvell mv78xx0 and kirkwood (armv5 pj1) were fairly
powerful in 2008 and could support at least 1GB of RAM,
but I only found one machine (OpenBlocks A7) that does
this. It's unclear if anyone is still updating kernels
on this machine, but they could /probably/ use
VMSPLIT_3G_OPT if they do.

* Microchip SAM9x7 is the newest ARMv5 chip, clearly does
get kernel updates, and the only one I can think of with
DDR3 support, but seems to be limited to 256MB total memory.

* The Gemini (ARMv4) platform enabled highmem as part of
commit c12d7e9fe9af ("ARM: defconfig: Update Gemini defconfig"),
but I don't see why, as the machine cited there only has
128MB of RAM in a contiguous chunk.

* A few ARMv4/v5 machines (omap1, davinci, ep93xx, clps71xx,
sa1100, riscpc) used to select CONFIG_ARCH_HAS_HOLES_MEMORYMODEL
or SPARSEMEM, which would indicate that they might need
highmem even for <1GB configurations if their memory banks are
far apart in physical memory. I checked those and as far
as I can tell, they are always within 768MB or less.

Arnd