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

David Hildenbrand (Red Hat)
2026-01-19T10:12:56Z

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