Re: [PATCH v3 7/7] mm: make PT_RECLAIM depends on MMU_GATHER_RCU_TABLE_FREE

["David Hildenbrand (Red Hat)" <david@kernel.org>]

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 <zhengqi.arch@bytedance.com>
>>>
>>> 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 <zhengqi.arch@bytedance.com>
>>> ---
>>>    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)" <david@kernel.org>
>> 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) <david@kernel.org>
>> ---
>>    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