On 18.11.25 13:02, Qi Zheng wrote:
On 11/18/25 12:57 AM, David Hildenbrand (Red Hat) wrote:
On 14.11.25 12:11, Qi Zheng wrote:
From: Qi Zheng <[email protected]>
Subject: s/&&/&/
will do.
Make PT_RECLAIM depend on MMU_GATHER_RCU_TABLE_FREE so that PT_RECLAIM
can
be enabled by default on all architectures that support
MMU_GATHER_RCU_TABLE_FREE.
Considering that a large number of PTE page table pages (such as 100GB+)
can only be caused on a 64-bit system, let PT_RECLAIM also depend on
64BIT.
Signed-off-by: Qi Zheng <[email protected]>
---
arch/x86/Kconfig | 1 -
mm/Kconfig | 6 +-----
2 files changed, 1 insertion(+), 6 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index eac2e86056902..96bff81fd4787 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -330,7 +330,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 a5a90b169435d..e795fbd69e50c 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -1440,14 +1440,10 @@ 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
+ depends on MMU_GATHER_RCU_TABLE_FREE && MMU && SMP && 64BIT
Who would we have MMU_GATHER_RCU_TABLE_FREE without MMU? (can we drop
the MMU part)
OK.
Why do we care about SMP in the first place? (can we frop SMP)
OK.
But I also wonder why we need "MMU_GATHER_RCU_TABLE_FREE && 64BIT":
Would it be harmful on 32bit (sure, we might not reclaim as much, but
still there is memory to be reclaimed?)?
This is also fine on 32bit, but the benefits are not significant, So I
chose to enable it only on 64-bit.
Right. Address space is smaller, but also memory is smaller. Not that I
think we strictly *must* to support 32bit, I merely wonder why we
wouldn't just enable it here.
OTOH, if there is a good reason we cannot enable it, we can definitely
just keep it 64bit only.
I actually tried enabling MMU_GATHER_RCU_TABLE_FREE on all
architectures, and apart from sparc32 being a bit troublesome (because
it uses mm->page_table_lock for synchronization within
__pte_free_tlb()), the modifications were relatively simple.
If all 64BIT support MMU_GATHER_RCU_TABLE_FREE (as you previously
state), why can't we only check for 64BIT?
OK, will do.
This was also more of a question for discussion:
Would it make sense to have
config PT_RECLAIM
def_bool y
depends on MMU_GATHER_RCU_TABLE_FREE
(a) Would we want to make it configurable (why?)
(b) Do we really care about SMP (why?)
(c) Do we want to limit to 64bit (why?)
(d) Do we really need the MMU check in addition to
MMU_GATHER_RCU_TABLE_FREE
--
Cheers
David
