| Message ID | 20241210160556.2341497-4-arnd@kernel.org (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | ARM: towards 32-bit preempt-rt support | expand |
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.
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 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
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))