Message-Id: <591bf41e-fe87-49b3-9a45-ce0dff1b8fba@app.fastmail.com>
Date: Wed, 10 Sep 2025 22:13:06 +0200
From: "Arnd Bergmann" <arnd@...db.de>
To: "Christophe Leroy" <christophe.leroy@...roup.eu>,
 "Michael Ellerman" <mpe@...erman.id.au>,
 "Nicholas Piggin" <npiggin@...il.com>,
 "Madhavan Srinivasan" <maddy@...ux.ibm.com>
Cc: linux-kernel@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org
Subject: Re: [RFC PATCH] powerpc: Remove CONFIG_HIGHMEM

On Wed, Sep 10, 2025, at 15:47, Christophe Leroy wrote:
> There are some discussion around to opportunity to get rid of
> CONFIG_HIGHMEM, see [1]. This RFC is a tentative to remove it
> from powerpc so that people can experiment what it would
> look like and what would be the outcomes.
>
> CONFIG_HIGHMEM is being depracated, remove it.
>
> To accomodate boards with up to 1Gbytes RAM, PAGE_OFFSET and
> TASK_SIZE is adjusted to 0xb0000000 (a0000000 on book3s/32 with modules).
>
> If you have more than 1Gbytes of RAM you can adjust CONFIG_LOWMEM_SIZE.
>
> [1] 
> https://lore.kernel.org/all/4ff89b72-03ff-4447-9d21-dd6a5fe1550f@app.fastmail.com/
>
> Signed-off-by: Christophe Leroy <christophe.leroy@...roup.eu>

Thanks for going through this, even if we keep partial highmem
support alive a little longer, it's good to know what the pieces
are that would go away. I think the majority of these already
removes stuff that no longer has any function, but there are
obviously a couple of machines that use highmem today, even
after changing the LOWMEM_SIZE setting.

I took a closer look at the ones that had CONFIG_HIGHMEM set
in the defconfig (I tried to look earlier for powerpc boards
but didn't have the idea to check the config) and found a
handful of machines that were able to use 2GB on MPC8572E,
MPC8640D or QorIQ P20xx, as well as two that have 4GB.

As with the Arm boards, the 2GB configurations may work
by further changing the LOWMEM_SIZE etc, but this has
a higher risk of breaking either drivers or applications.

The 4GB configs are obviously more problematic, no LOWMEM_SIZE
setting can give back the memory lost from disabling highmem.
Two options we are discussing for those are either leaving
highmem only as zram backing store long-term, or leaving it
for page cache only.

There is also a related setting:

config PHYS_64BIT
        bool 'Large physical address support' if PPC_E500 || PPC_86xx
        depends on (44x || PPC_E500 || PPC_86xx) && !PPC_83xx && !PPC_82xx
        select PHYS_ADDR_T_64BIT

This is currently enabled in 85xx-32bit.config, and probably
required specifically for the boards that have 4GB of RAM,
as the PCI MMIO space starts at physical address 0x80000000 (2GB)
on the qoriq and mpc8641 boards.

The PHYS_64BIT option itself should probably use
'depends on HIGHMEM'.

> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 93402a1d9c9f..fec1db5fcb97 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -482,11 +482,6 @@ source "arch/powerpc/platforms/Kconfig"
> 
>  menu "Kernel options"
> 
> -config HIGHMEM
> -	bool "High memory support"
> -	depends on PPC32
> -	select KMAP_LOCAL
> -

This could stay guarded by 'depends on EXPERT' in that case.

> @@ -1193,7 +1188,7 @@ config LOWMEM_SIZE_BOOL
> 
>  config LOWMEM_SIZE
>  	hex "Maximum low memory size (in bytes)" if LOWMEM_SIZE_BOOL
> -	default "0x30000000"
> +	default "0x40000000"
> 
>  config LOWMEM_CAM_NUM_BOOL
>  	bool "Set number of CAMs to use to map low memory"
> @@ -1245,7 +1240,7 @@ config PAGE_OFFSET_BOOL
> 
>  config PAGE_OFFSET
>  	hex "Virtual address of memory base" if PAGE_OFFSET_BOOL
> -	default "0xc0000000"
> +	default "0xb0000000"
> 
>  config KERNEL_START_BOOL
>  	bool "Set custom kernel base address"
>
> @@ -1298,8 +1293,8 @@ config TASK_SIZE_BOOL
>  config TASK_SIZE
>  	hex "Size of user task space" if TASK_SIZE_BOOL
>  	default "0x80000000" if PPC_8xx
> -	default "0xb0000000" if PPC_BOOK3S_32 && EXECMEM
> -	default "0xc0000000"
> +	default "0xa0000000" if PPC_BOOK3S_32 && EXECMEM
> +	default "0xb0000000"
> 
>  config MODULES_SIZE_BOOL
>  	bool "Set custom size for modules/execmem area"

These all look good to me, as I suggested we should do the
same thing on arm and x86 using CONFIG_VMSPLIT_3G_OPT
as the default.

> diff --git a/arch/powerpc/configs/85xx-32bit.config 
> b/arch/powerpc/configs/85xx-32bit.config
> index a85310bcb1fd..f96db0bc888f 100644
> --- a/arch/powerpc/configs/85xx-32bit.config
> +++ b/arch/powerpc/configs/85xx-32bit.config
> @@ -1,5 +1,4 @@
>  CONFIG_PPC64=n
> -CONFIG_HIGHMEM=y
>  CONFIG_KEXEC=y
>  CONFIG_PPC_85xx=y
>  CONFIG_PROC_KCORE=y

I know the nic.cz Turris has a P2020 CPU and 2GB.

> diff --git a/arch/powerpc/configs/85xx/ge_imp3a_defconfig 
> b/arch/powerpc/configs/85xx/ge_imp3a_defconfig
> index 7beb36a41d45..da9f649107dc 100644
> --- a/arch/powerpc/configs/85xx/ge_imp3a_defconfig
> +++ b/arch/powerpc/configs/85xx/ge_imp3a_defconfig
> @@ -23,7 +23,6 @@ CONFIG_MODULE_UNLOAD=y
>  CONFIG_GE_IMP3A=y
>  CONFIG_QE_GPIO=y
>  CONFIG_CPM2=y
> -CONFIG_HIGHMEM=y
>  CONFIG_HZ_1000=y
>  CONFIG_PREEMPT=y
>  # CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set

I see that IMP3A has 4GB of DDR3 memory, so  this one
clearly depends on HIGHMEM for actual users if any remain.

https://abaco.com/products/powerpact3-imp3a/p3516 shows
it has "entered a Restricted Production Phase (RPP) on August
28, 2020", which was roughly when NXP discontinued the
QORIQ P2 CPU, and 10 years after it was first introduced.

This was targeted at the military and aerospace markets,
so there is a good chance that some are still in use, but
I have no idea whether any of the users are planning to
update the kernels.

> diff --git a/arch/powerpc/configs/85xx/xes_mpc85xx_defconfig 
> b/arch/powerpc/configs/85xx/xes_mpc85xx_defconfig
> index 488d03ae6d6c..10764fad2eb9 100644
> --- a/arch/powerpc/configs/85xx/xes_mpc85xx_defconfig
> +++ b/arch/powerpc/configs/85xx/xes_mpc85xx_defconfig
> @@ -18,7 +18,6 @@ CONFIG_MODVERSIONS=y
>  # CONFIG_BLK_DEV_BSG is not set
>  CONFIG_PARTITION_ADVANCED=y
>  CONFIG_XES_MPC85xx=y
> -CONFIG_HIGHMEM=y
>  CONFIG_MATH_EMULATION=y
>  CONFIG_PCI=y
>  CONFIG_PCIEPORTBUS=y

Same here: 2-4GB DDR3, sold 2009-2018
https://www.xes-inc.com/products/end-of-life-sbcs/xcalibur1501/

> diff --git a/arch/powerpc/configs/chrp32_defconfig 
> b/arch/powerpc/configs/chrp32_defconfig
> index b799c95480ae..304de18b51f8 100644
> --- a/arch/powerpc/configs/chrp32_defconfig
> +++ b/arch/powerpc/configs/chrp32_defconfig
> @@ -17,7 +17,6 @@ CONFIG_PARTITION_ADVANCED=y
>  CONFIG_MAC_PARTITION=y
>  # CONFIG_PPC_PMAC is not set
>  CONFIG_GEN_RTC=y
> -CONFIG_HIGHMEM=y
>  CONFIG_BINFMT_MISC=y
>  CONFIG_IRQ_ALL_CPUS=y
>  CONFIG_ISA=y

Apparently the Pegasos-II could support 2GB if you had the right
board revision and memory.

> diff --git a/arch/powerpc/configs/mpc86xx_base.config 
> b/arch/powerpc/configs/mpc86xx_base.config
> index 632c014b122d..a1ca1f7da240 100644
> --- a/arch/powerpc/configs/mpc86xx_base.config
> +++ b/arch/powerpc/configs/mpc86xx_base.config
> @@ -3,6 +3,5 @@ CONFIG_GEF_PPC9A=y
>  CONFIG_GEF_SBC310=y
>  CONFIG_GEF_SBC610=y
>  CONFIG_MVME7100=y
> -CONFIG_HIGHMEM=y
>  CONFIG_KEXEC=y
>  CONFIG_PROC_KCORE=y

There are four 8640 based boards enabled here, three of them
support 2GB RAM. Apparently the MVME7100 still has "limited
availablilty, the others were discontinued in 2018 or before.

> diff --git a/arch/powerpc/configs/pmac32_defconfig 
> b/arch/powerpc/configs/pmac32_defconfig
> index ae45f70b29f0..24e73489947a 100644
> --- a/arch/powerpc/configs/pmac32_defconfig
> +++ b/arch/powerpc/configs/pmac32_defconfig
> @@ -20,7 +20,6 @@ CONFIG_CPU_FREQ_GOV_POWERSAVE=y
>  CONFIG_CPU_FREQ_GOV_USERSPACE=y
>  CONFIG_CPU_FREQ_PMAC=y
>  CONFIG_GEN_RTC=y
> -CONFIG_HIGHMEM=y
>  CONFIG_BINFMT_MISC=m
>  CONFIG_HIBERNATION=y
>  CONFIG_PM_DEBUG=y

A couple of G4 Macs could be upgraded to 2GB.

> diff --git a/arch/powerpc/configs/ppc6xx_defconfig 
> b/arch/powerpc/configs/ppc6xx_defconfig
> index bb359643ddc1..75b44ce12332 100644
> --- a/arch/powerpc/configs/ppc6xx_defconfig
> +++ b/arch/powerpc/configs/ppc6xx_defconfig
> @@ -60,7 +60,6 @@ CONFIG_TAU=y
>  CONFIG_TAU_AVERAGE=y
>  CONFIG_QE_GPIO=y
>  CONFIG_MCU_MPC8349EMITX=y
> -CONFIG_HIGHMEM=y
>  CONFIG_HZ_1000=y
>  CONFIG_PREEMPT_VOLUNTARY=y
>  CONFIG_BINFMT_MISC=y

This includes the mpc86xx boards from mpc86xx_base config.

> diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
> index d79c5d1098c0..7489557f582a 100644
> --- a/arch/powerpc/kvm/book3s.c
> +++ b/arch/powerpc/kvm/book3s.c
> @@ -20,7 +20,6 @@
>  #include <linux/gfp.h>
>  #include <linux/sched.h>
>  #include <linux/vmalloc.h>
> -#include <linux/highmem.h>
> 
>  #include <asm/reg.h>
>  #include <asm/cputable.h>

Right, all the linux/highmem.h inclusions are probably unnecessary
regardless.

> diff --git a/arch/powerpc/platforms/ps3/system-bus.c 
> b/arch/powerpc/platforms/ps3/system-bus.c
> index afbaabf182d0..1f20311ed0c9 100644
> --- a/arch/powerpc/platforms/ps3/system-bus.c
> +++ b/arch/powerpc/platforms/ps3/system-bus.c
> @@ -510,7 +510,7 @@ static void * ps3_alloc_coherent(struct device 
> *_dev, size_t size,
>  	struct ps3_system_bus_device *dev = ps3_dev_to_system_bus_dev(_dev);
>  	unsigned long virt_addr;
> 
> -	flag &= ~(__GFP_DMA | __GFP_HIGHMEM);
> +	flag &= ~__GFP_DMA;
>  	flag |= __GFP_ZERO;
> 
>  	virt_addr = __get_free_pages(flag, get_order(size));

This should never have used __GFP_HIGHMEM since it does not support
32-bit kernels.

    Arnd

Powered by blists - more mailing lists