From: Arnd Bergmann <arnd@arndb.de>
CONFIG_HIGHPTE was added in linux-2.6.32, a few years before 64-bit
support. At the time it made sense, as the CONFIG_ARM_LPAE option allowed
systems with 16GB of memory that made lowmem a particularly scarce
resource, and the HIGHPTE implementation gave feature parity with 32-bit
x86 and frv machines.
Since Arm is the last architecture remaining that uses this, and almost
no 32-bit machines support more than 4GB of RAM, the cost of continuing
to maintain HIGHPTE seems unjustified, so remove it here to allow
simplifying the generic page table handling.
Link: https://lore.kernel.org/lkml/20241204103042.1904639-8-arnd@kernel.org/T/#u
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
I sent a patch to drop HIGHPTE support on x86 today, see
https://lore.kernel.org/lkml/20241210144945.2325330-9-arnd@kernel.org/T/#u
If that one gets merged, we can merge this one instead of the one
that makes HIGHPTE depend on !PREEMPT_RT, but if we decide against
the x86 change, then we probably don't want this one either.
---
arch/arm/Kconfig | 11 -----------
arch/arm/include/asm/pgalloc.h | 8 +-------
2 files changed, 1 insertion(+), 18 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 4de4e5697bdf..e132effafd8b 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 && !PREEMPT_RT
- 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/include/asm/pgalloc.h b/arch/arm/include/asm/pgalloc.h
index a17f01235c29..ef6cb3e6d179 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))
--
2.39.5From: Arnd Bergmann > Sent: 10 December 2024 16:06 ... > Since Arm is the last architecture remaining that uses this, and almost > no 32-bit machines support more than 4GB of RAM, the cost of continuing > to maintain HIGHPTE seems unjustified, so remove it here to allow > simplifying the generic page table handling. 'Picking at nits' 'highmem' support was needed for systems with 4GB of RAM in order to use more than 3GB or 3.5GB (depending on the bios) because of the physical addresses that are reserved for PCI (and other MMIO). David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
On Sat, Dec 14, 2024 at 7:41 PM David Laight <David.Laight@aculab.com> wrote: > From: Arnd Bergmann > > Sent: 10 December 2024 16:06 > ... > > Since Arm is the last architecture remaining that uses this, and almost > > no 32-bit machines support more than 4GB of RAM, the cost of continuing > > to maintain HIGHPTE seems unjustified, so remove it here to allow > > simplifying the generic page table handling. > > 'Picking at nits' 'highmem' support was needed for systems with 4GB of RAM > in order to use more than 3GB or 3.5GB (depending on the bios) because > of the physical addresses that are reserved for PCI (and other MMIO). Wow I didn't know that, there are so many reasons why highmem is used by different architectures. On ARM it was originally added for a certain Marvell system with a mere 2GB of RAM: commit 053a96ca11a9785a7e63fc89eed4514a6446ec58 The reason was that since the virtual address space is just 4GB and we have reserved virtual kernel memory from (typically) 0xc0000000 only ~1GB can be linearly accessed by the kernel (actually less than that). This wasn't a problem since no ARM system was using more than 1GB until Nico ran into it. So the ARM "high memory" is something to do with virtual memory size rather than physical memory reservations as in the x86 case. Yours, Linus Walleij
On 2024-12-10 17:05:55 [+0100], Arnd Bergmann wrote: > From: Arnd Bergmann <arnd@arndb.de> > > CONFIG_HIGHPTE was added in linux-2.6.32, a few years before 64-bit > support. At the time it made sense, as the CONFIG_ARM_LPAE option allowed > systems with 16GB of memory that made lowmem a particularly scarce > resource, and the HIGHPTE implementation gave feature parity with 32-bit > x86 and frv machines. > > Since Arm is the last architecture remaining that uses this, and almost > no 32-bit machines support more than 4GB of RAM, the cost of continuing > to maintain HIGHPTE seems unjustified, so remove it here to allow > simplifying the generic page table handling. > > Link: https://lore.kernel.org/lkml/20241204103042.1904639-8-arnd@kernel.org/T/#u > Signed-off-by: Arnd Bergmann <arnd@arndb.de> > --- > I sent a patch to drop HIGHPTE support on x86 today, see > https://lore.kernel.org/lkml/20241210144945.2325330-9-arnd@kernel.org/T/#u > > If that one gets merged, we can merge this one instead of the one > that makes HIGHPTE depend on !PREEMPT_RT, but if we decide against > the x86 change, then we probably don't want this one either. Based on what I have written in 20241211140402.yf7gMExr@linutronix.de it makes sense. Acked-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Sebastian
On Tue, Dec 10, 2024 at 5:06 PM Arnd Bergmann <arnd@kernel.org> wrote: > From: Arnd Bergmann <arnd@arndb.de> > > CONFIG_HIGHPTE was added in linux-2.6.32, a few years before 64-bit > support. At the time it made sense, as the CONFIG_ARM_LPAE option allowed > systems with 16GB of memory that made lowmem a particularly scarce > resource, and the HIGHPTE implementation gave feature parity with 32-bit > x86 and frv machines. > > Since Arm is the last architecture remaining that uses this, and almost > no 32-bit machines support more than 4GB of RAM, the cost of continuing > to maintain HIGHPTE seems unjustified, so remove it here to allow > simplifying the generic page table handling. > > Link: https://lore.kernel.org/lkml/20241204103042.1904639-8-arnd@kernel.org/T/#u > Signed-off-by: Arnd Bergmann <arnd@arndb.de> I'm in favor of this if the x86 patch goes in. We need to get rid of highmem anyway and this will need to happen sooner or later either way. Acked-by: Linus Walleij <linus.walleij@linaro.org> Yours, Linus Walleij
On Wed, Dec 11, 2024 at 02:32:51PM +0100, Linus Walleij wrote: > On Tue, Dec 10, 2024 at 5:06 PM Arnd Bergmann <arnd@kernel.org> wrote: > > > From: Arnd Bergmann <arnd@arndb.de> > > > > CONFIG_HIGHPTE was added in linux-2.6.32, a few years before 64-bit > > support. At the time it made sense, as the CONFIG_ARM_LPAE option allowed > > systems with 16GB of memory that made lowmem a particularly scarce > > resource, and the HIGHPTE implementation gave feature parity with 32-bit > > x86 and frv machines. > > > > Since Arm is the last architecture remaining that uses this, and almost > > no 32-bit machines support more than 4GB of RAM, the cost of continuing > > to maintain HIGHPTE seems unjustified, so remove it here to allow > > simplifying the generic page table handling. > > > > Link: https://lore.kernel.org/lkml/20241204103042.1904639-8-arnd@kernel.org/T/#u > > Signed-off-by: Arnd Bergmann <arnd@arndb.de> > > I'm in favor of this if the x86 patch goes in. We need to get rid > of highmem anyway and this will need to happen sooner or later > either way. Well... I use highmem routinely. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
On Wed, Dec 11, 2024 at 2:51 PM Russell King (Oracle)
<linux@armlinux.org.uk> wrote:
> On Wed, Dec 11, 2024 at 02:32:51PM +0100, Linus Walleij wrote:
> > On Tue, Dec 10, 2024 at 5:06 PM Arnd Bergmann <arnd@kernel.org> wrote:
> >
> > > From: Arnd Bergmann <arnd@arndb.de>
> > >
> > > CONFIG_HIGHPTE was added in linux-2.6.32, a few years before 64-bit
> > > support. At the time it made sense, as the CONFIG_ARM_LPAE option allowed
> > > systems with 16GB of memory that made lowmem a particularly scarce
> > > resource, and the HIGHPTE implementation gave feature parity with 32-bit
> > > x86 and frv machines.
> > >
> > > Since Arm is the last architecture remaining that uses this, and almost
> > > no 32-bit machines support more than 4GB of RAM, the cost of continuing
> > > to maintain HIGHPTE seems unjustified, so remove it here to allow
> > > simplifying the generic page table handling.
> > >
> > > Link: https://lore.kernel.org/lkml/20241204103042.1904639-8-arnd@kernel.org/T/#u
> > > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> >
> > I'm in favor of this if the x86 patch goes in. We need to get rid
> > of highmem anyway and this will need to happen sooner or later
> > either way.
>
> Well... I use highmem routinely.
Oh I don't mean we should get rid of it without any replacement. Certainly
systems with big physical memories need to be usable.
I am pursuing two ideas (inspired by Arnd and MM people):
1. The easy option - "densemem", on systems with a "hole" in the physical
memory making the 1:1 linear phys-to-virt map run out too soon and
overconsume virual memory, actually collect the physical memory on low
virtual addresses by elaborate phys-to-virt virt-to-phys and page
numbering that isn't 1:1.
2. The hard option - 4G-by-4G splitting, making the kernel and userspace
virtual memory spaces separate as it is in hardware on S/390, so the
kernel can use a while 4G of memory for its needs. I banged my head
against this a fair amount of time, so I might be incompetent to do it,
but I still try.
Yours,
Linus Walleij
© 2016 - 2025 Red Hat, Inc.