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
