On 1/19/26 04:50, Qi Zheng wrote:
On 1/18/26 7:23 PM, David Hildenbrand (Red Hat) wrote:
On 12/17/25 10:45, Qi Zheng wrote:
From: Qi Zheng <[email protected]>
The PT_RECLAIM can work on all architectures that support
MMU_GATHER_RCU_TABLE_FREE, so make PT_RECLAIM depends on
MMU_GATHER_RCU_TABLE_FREE.
BTW, change PT_RECLAIM to be enabled by default, since nobody should want
to turn it off.
Signed-off-by: Qi Zheng <[email protected]>
---
arch/x86/Kconfig | 1 -
mm/Kconfig | 9 ++-------
2 files changed, 2 insertions(+), 8 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 80527299f859a..0d22da56a71b0 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -331,7 +331,6 @@ config X86
select FUNCTION_ALIGNMENT_4B
imply IMA_SECURE_AND_OR_TRUSTED_BOOT if EFI
select HAVE_DYNAMIC_FTRACE_NO_PATCHABLE
- select ARCH_SUPPORTS_PT_RECLAIM if X86_64
select ARCH_SUPPORTS_SCHED_SMT if SMP
select SCHED_SMT if SMP
select ARCH_SUPPORTS_SCHED_CLUSTER if SMP
diff --git a/mm/Kconfig b/mm/Kconfig
index bd0ea5454af82..fc00b429b7129 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -1447,14 +1447,9 @@ config ARCH_HAS_USER_SHADOW_STACK
The architecture has hardware support for userspace shadow call
stacks (eg, x86 CET, arm64 GCS or RISC-V Zicfiss).
-config ARCH_SUPPORTS_PT_RECLAIM
- def_bool n
-
config PT_RECLAIM
- bool "reclaim empty user page table pages"
- default y
- depends on ARCH_SUPPORTS_PT_RECLAIM && MMU && SMP
- select MMU_GATHER_RCU_TABLE_FREE
+ def_bool y
+ depends on MMU_GATHER_RCU_TABLE_FREE
help
Try to reclaim empty user page table pages in paths other than
munmap
and exit_mmap path.
This patch seems to make s390x compilations sometimes unhappy:
Unverified Warning (likely false positive, kindly check if interested):
I believe it is a false positive.
mm/memory.c:1911 zap_pte_range() error: uninitialized symbol 'pmdval'.
Warning ids grouped by kconfigs:
recent_errors
`-- s390-randconfig-r072-20260117
`-- mm-memory.c-zap_pte_range()-error:uninitialized-symbol-pmdval-.
I assume the compiler is not able to figure out that only when
try_get_and_clear_pmd() returns false that pmdval could be uninitialized.
Maybe it has to do with LTO?
After all, that function resides in a different compilation unit.
Which makes me wonder whether we want to just move try_get_and_clear_pmd()
and reclaim_pt_is_enabled() to internal.h or even just memory.c?
But then, maybe we could remove pt_reclaim.c completely and just have
try_to_free_pte() in memory.c as well?
I would just do the following cleanup:
From cfe97092f71fcc88f729f07ee0bc6816e3e398f0 Mon Sep 17 00:00:00 2001
From: "David Hildenbrand (Red Hat)" <[email protected]>
Date: Sun, 18 Jan 2026 12:20:55 +0100
Subject: [PATCH] mm: move pte table reclaim code to memory.c
Let's move the code and clean it up a bit along the way.
Signed-off-by: David Hildenbrand (Red Hat) <[email protected]>
---
MAINTAINERS | 1 -
mm/internal.h | 18 -------------
mm/memory.c | 70 ++++++++++++++++++++++++++++++++++++++++++-----
mm/pt_reclaim.c | 72 -------------------------------------------------
4 files changed, 64 insertions(+), 97 deletions(-)
delete mode 100644 mm/pt_reclaim.c
Make sense, and LGTM. The reason it was placed in mm/pt_reclaim.c before
was because there would be other paths calling these functions in the
future. However, it can be separated out or put into a header file when
there are actually such callers.
Most relevant zapping better happens in memory.c :)
There is, of course, zapping due to RMAP unmap, but that mostly targets
individual PTEs, and not a complete pte table.
Likely, if ever required, we should expose a proper zapping interface
from memory.c to other users, assuming the existing one is not suitable.
would you be willing to send out an official patch?
Yes, I can send one out, thanks.
--
Cheers
David
