Matthew Wilcox suggests HIGHPTE is a burden for the
kernel MM, and only one ARM system (vt8500) is currently
using it.

This deletes the use of HIGHPTE in ARM32 clearing the way
to remove the feature altogether.

It was introduced in commit 65cec8e3db60 "ARM: implement highpte"
in 2009, so this RFC is intended as a discussion item to
check if it is still a desired feature 16 years later
or if we can get rid of it.

To: Russell King <rmk+kernel@armlinux.org.uk>
To: Matthew Wilcox <willy@infradead.org>
To: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/linux-arm-kernel/aMDYdp3H-yOHU1Pm@casper.infradead.org/
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
 arch/arm/Kconfig                        | 11 -----------
 arch/arm/configs/vt8500_v6_v7_defconfig |  1 -
 arch/arm/include/asm/pgalloc.h          |  8 +-------
 3 files changed, 1 insertion(+), 19 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index b1f3df39ed4068f215a3460d5c4e021136438eaa..5545583946a2433f86a5ba2d6ade34f5e931ae74 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1229,17 +1229,6 @@ config HIGHMEM
 
 	  If unsure, say n.
 
-config HIGHPTE
-	bool "Allocate 2nd-level pagetables from highmem" if EXPERT
-	depends on HIGHMEM
-	default y
-	help
-	  The VM uses one page of physical memory for each page table.
-	  For systems with a lot of processes, this can use a lot of
-	  precious low memory, eventually leading to low memory being
-	  consumed by page tables.  Setting this option will allow
-	  user-space 2nd level page tables to reside in high memory.
-
 config ARM_PAN
 	bool "Enable privileged no-access"
 	depends on MMU
diff --git a/arch/arm/configs/vt8500_v6_v7_defconfig b/arch/arm/configs/vt8500_v6_v7_defconfig
index 41607a84abc85adfc9d8d2d520354576e1e274d2..a91e6547378136b3e1264aaddcac7d6ddb66987d 100644
--- a/arch/arm/configs/vt8500_v6_v7_defconfig
+++ b/arch/arm/configs/vt8500_v6_v7_defconfig
@@ -10,7 +10,6 @@ CONFIG_ARM_ERRATA_775420=y
 CONFIG_HAVE_ARM_ARCH_TIMER=y
 CONFIG_AEABI=y
 CONFIG_HIGHMEM=y
-CONFIG_HIGHPTE=y
 CONFIG_ARM_APPENDED_DTB=y
 CONFIG_ARM_ATAG_DTB_COMPAT=y
 CONFIG_VFP=y
diff --git a/arch/arm/include/asm/pgalloc.h b/arch/arm/include/asm/pgalloc.h
index a17f01235c29c0dc619c0929aa761df861a5dd2d..ef6cb3e6d179e63c7edbcaf69e6b21847b354a0f 100644
--- a/arch/arm/include/asm/pgalloc.h
+++ b/arch/arm/include/asm/pgalloc.h
@@ -85,18 +85,12 @@ pte_alloc_one_kernel(struct mm_struct *mm)
 	return pte;
 }
 
-#ifdef CONFIG_HIGHPTE
-#define PGTABLE_HIGHMEM __GFP_HIGHMEM
-#else
-#define PGTABLE_HIGHMEM 0
-#endif
-
 static inline pgtable_t
 pte_alloc_one(struct mm_struct *mm)
 {
 	struct page *pte;
 
-	pte = __pte_alloc_one(mm, GFP_PGTABLE_USER | PGTABLE_HIGHMEM);
+	pte = __pte_alloc_one(mm, GFP_PGTABLE_USER);
 	if (!pte)
 		return NULL;
 	if (!PageHighMem(pte))

---
base-commit: 8f5ae30d69d7543eee0d70083daf4de8fe15d585
change-id: 20250910-arm-remove-high-pte-6ead9c6eb336

Best regards,
-- 
Linus Walleij <linus.walleij@linaro.org>

On Wed, Sep 10, 2025, at 11:47, Linus Walleij wrote:
> Matthew Wilcox suggests HIGHPTE is a burden for the
> kernel MM, and only one ARM system (vt8500) is currently
> using it.

I think the vt8500_v6_v7_defconfig entry is a historic leftover,
instead it is currently enabled by default on all configurations
that enable highmem.

> This deletes the use of HIGHPTE in ARM32 clearing the way
> to remove the feature altogether.
>
> It was introduced in commit 65cec8e3db60 "ARM: implement highpte"
> in 2009, so this RFC is intended as a discussion item to
> check if it is still a desired feature 16 years later
> or if we can get rid of it.

We discussed it last year in the context of the PREEMPT_RT patches, see
https://lore.kernel.org/linux-arm-kernel/20241210160556.2341497-4-arnd@kernel.org/
and Russell's reply to that.

I still think that dropping it is the sensible tradeoff here in
the end, as it should allow further simplifications in the
pgalloc code. Your version of this patch doesn't (like my
identical patch from December) actually do any of that though.

> -	pte = __pte_alloc_one(mm, GFP_PGTABLE_USER | PGTABLE_HIGHMEM);
> +	pte = __pte_alloc_one(mm, GFP_PGTABLE_USER);
>  	if (!pte)
>  		return NULL;
>  	if (!PageHighMem(pte))

At the minimum, PageHighMem(pte) is now know to be false, so
this could be further simplified. I tried figuring out if we can
remove __HAVE_ARCH_PTE_ALLOC_ONE altogether, but I'm not sure
where else the clean_pte_table() call on arm would happen.

   Arnd

On Wed, Sep 10, 2025 at 2:15 PM Arnd Bergmann <arnd@arndb.de> wrote:
> On Wed, Sep 10, 2025, at 11:47, Linus Walleij wrote:
> > Matthew Wilcox suggests HIGHPTE is a burden for the
> > kernel MM, and only one ARM system (vt8500) is currently
> > using it.
>
> I think the vt8500_v6_v7_defconfig entry is a historic leftover,
> instead it is currently enabled by default on all configurations
> that enable highmem.
>
> > This deletes the use of HIGHPTE in ARM32 clearing the way
> > to remove the feature altogether.
> >
> > It was introduced in commit 65cec8e3db60 "ARM: implement highpte"
> > in 2009, so this RFC is intended as a discussion item to
> > check if it is still a desired feature 16 years later
> > or if we can get rid of it.
>
> We discussed it last year in the context of the PREEMPT_RT patches, see
> https://lore.kernel.org/linux-arm-kernel/20241210160556.2341497-4-arnd@kernel.org/
> and Russell's reply to that.
>
> I still think that dropping it is the sensible tradeoff here in
> the end, as it should allow further simplifications in the
> pgalloc code. Your version of this patch doesn't (like my
> identical patch from December) actually do any of that though.

Ah, I was blissfully unaware of that patch, sorry.

If we go any further with this let's rebase your patch instead.

Yours,
Linus Walleij

On Wed, Sep 10, 2025 at 2:25 PM Linus Walleij <linus.walleij@linaro.org> wrote:

> Ah, I was blissfully unaware of that patch, sorry.

Actually that is a weird thing of me to say about a patch that
I even replied to.

I had *blatantly forgot* about that patch would be a more
accurate statement...

Yours,
Linus Walleij