From: Qi Zheng <zhengqi.arch@bytedance.com>
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 <zhengqi.arch@bytedance.com>
---
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
help
Try to reclaim empty user page table pages in paths other than munmap
and exit_mmap path.
--
2.20.1On 14.11.25 12:11, Qi Zheng wrote: > From: Qi Zheng <zhengqi.arch@bytedance.com> Subject: s/&&/&/ > > 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 <zhengqi.arch@bytedance.com> > --- > 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) Why do we care about SMP in the first place? (can we frop SMP) 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?)? If all 64BIT support MMU_GATHER_RCU_TABLE_FREE (as you previously state), why can't we only check for 64BIT? -- Cheers David
On 11/18/25 12:57 AM, David Hildenbrand (Red Hat) wrote: > On 14.11.25 12:11, Qi Zheng wrote: >> From: Qi Zheng <zhengqi.arch@bytedance.com> > > 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 <zhengqi.arch@bytedance.com> >> --- >> 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. 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. Thanks, Qi >
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 <zhengqi.arch@bytedance.com>
>>
>> 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 <zhengqi.arch@bytedance.com>
>>> ---
>>> 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
Hi David,
On 11/19/25 6:19 PM, David Hildenbrand (Red Hat) wrote:
> 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 <zhengqi.arch@bytedance.com>
>>>
>>> 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 <zhengqi.arch@bytedance.com>
>>>> ---
>>>> 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.
The only difficulty is this:
>
>>
>> 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.
in sparc32:
void pte_free(struct mm_struct *mm, pgtable_t ptep)
{
struct page *page;
page = pfn_to_page(__nocache_pa((unsigned long)ptep) >>
PAGE_SHIFT);
spin_lock(&mm->page_table_lock);
if (page_ref_dec_return(page) == 1)
pagetable_dtor(page_ptdesc(page));
spin_unlock(&mm->page_table_lock);
srmmu_free_nocache(ptep, SRMMU_PTE_TABLE_SIZE);
}
#define __pte_free_tlb(tlb, pte, addr) pte_free((tlb)->mm, pte)
To enable MMU_GATHER_RCU_TABLE_FREE on sparc32, we need to implement
__tlb_remove_table(), and call the pte_free() above in __tlb_remove_table().
However, the __tlb_remove_table() does not have an mm parameter:
void __tlb_remove_table(void *_table)
so we need to use another lock instead of mm->page_table_lock.
I have already sent the v2 [1], and perhaps after that I can enable
PT_RECLAIM on all 32-bit architectures as well.
[1].
https://lore.kernel.org/all/cover.1763537007.git.zhengqi.arch@bytedance.com/
>>
>>>
>>> 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
make sense.
>
> (a) Would we want to make it configurable (why?)
No, it was just out of caution before.
> (b) Do we really care about SMP (why?)
No. Simply because the following situation is impossible to occur:
pte_offset_map
traversing the PTE page table
<preemption or hardirq>
call madvise(MADV_DONTNEED)
so there's no need to free PTE page via RCU.
> (c) Do we want to limit to 64bit (why?)
No, just because the profit is greater at 64-BIT.
> (d) Do we really need the MMU check in addition to
> MMU_GATHER_RCU_TABLE_FREE
No, I was worried about compilation issues before, but now it seems that
my worries were unnecessary.
Thanks,
Qi
>
>
On 19.11.25 12:02, Qi Zheng wrote:
> Hi David,
>
> On 11/19/25 6:19 PM, David Hildenbrand (Red Hat) wrote:
>> 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 <zhengqi.arch@bytedance.com>
>>>>
>>>> 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 <zhengqi.arch@bytedance.com>
>>>>> ---
>>>>> 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.
>
> The only difficulty is this:
>
>>
>>>
>>> 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.
>
> in sparc32:
>
> void pte_free(struct mm_struct *mm, pgtable_t ptep)
> {
> struct page *page;
>
> page = pfn_to_page(__nocache_pa((unsigned long)ptep) >>
> PAGE_SHIFT);
> spin_lock(&mm->page_table_lock);
> if (page_ref_dec_return(page) == 1)
> pagetable_dtor(page_ptdesc(page));
> spin_unlock(&mm->page_table_lock);
>
> srmmu_free_nocache(ptep, SRMMU_PTE_TABLE_SIZE);
> }
>
> #define __pte_free_tlb(tlb, pte, addr) pte_free((tlb)->mm, pte)
>
> To enable MMU_GATHER_RCU_TABLE_FREE on sparc32, we need to implement
> __tlb_remove_table(), and call the pte_free() above in __tlb_remove_table().
>
> However, the __tlb_remove_table() does not have an mm parameter:
>
> void __tlb_remove_table(void *_table)
>
> so we need to use another lock instead of mm->page_table_lock.
>
> I have already sent the v2 [1], and perhaps after that I can enable
> PT_RECLAIM on all 32-bit architectures as well.
>
I guess if we just make it depend on MMU_GATHER_RCU_TABLE_FREE that will
be fine.
> [1].
> https://lore.kernel.org/all/cover.1763537007.git.zhengqi.arch@bytedance.com/
>
>>>
>>>>
>>>> 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
>
> make sense.
>
>>
>> (a) Would we want to make it configurable (why?)
>
> No, it was just out of caution before.
>
>> (b) Do we really care about SMP (why?)
>
> No. Simply because the following situation is impossible to occur:
>
> pte_offset_map
> traversing the PTE page table
>
> <preemption or hardirq>
>
> call madvise(MADV_DONTNEED)
>
> so there's no need to free PTE page via RCU.
>
>> (c) Do we want to limit to 64bit (why?)
>
> No, just because the profit is greater at 64-BIT.
I was briefly wondering if on 32bit (but maybe also on 64bit with
configurable user page table levels?) we could have the scenario that we
only have two page table levels.
So reclaiming the PMD level (corresponding to the highest level) would
be impossible. But for that to happen one would have to discard the
whole address range through MADV_DONTNEED (impossible I guess) :)
--
Cheers
David
On 11/19/25 7:35 PM, David Hildenbrand (Red Hat) wrote:
> On 19.11.25 12:02, Qi Zheng wrote:
>> Hi David,
>>
>> On 11/19/25 6:19 PM, David Hildenbrand (Red Hat) wrote:
>>> 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 <zhengqi.arch@bytedance.com>
>>>>>
>>>>> 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 <zhengqi.arch@bytedance.com>
>>>>>> ---
>>>>>> 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.
>>
>> The only difficulty is this:
>>
>>>
>>>>
>>>> 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.
>>
>> in sparc32:
>>
>> void pte_free(struct mm_struct *mm, pgtable_t ptep)
>> {
>> struct page *page;
>>
>> page = pfn_to_page(__nocache_pa((unsigned long)ptep) >>
>> PAGE_SHIFT);
>> spin_lock(&mm->page_table_lock);
>> if (page_ref_dec_return(page) == 1)
>> pagetable_dtor(page_ptdesc(page));
>> spin_unlock(&mm->page_table_lock);
>>
>> srmmu_free_nocache(ptep, SRMMU_PTE_TABLE_SIZE);
>> }
>>
>> #define __pte_free_tlb(tlb, pte, addr) pte_free((tlb)->mm, pte)
>>
>> To enable MMU_GATHER_RCU_TABLE_FREE on sparc32, we need to implement
>> __tlb_remove_table(), and call the pte_free() above in
>> __tlb_remove_table().
>>
>> However, the __tlb_remove_table() does not have an mm parameter:
>>
>> void __tlb_remove_table(void *_table)
>>
>> so we need to use another lock instead of mm->page_table_lock.
>>
>> I have already sent the v2 [1], and perhaps after that I can enable
>> PT_RECLAIM on all 32-bit architectures as well.
>>
>
> I guess if we just make it depend on MMU_GATHER_RCU_TABLE_FREE that will
> be fine.
>
>> [1].
>> https://lore.kernel.org/all/
>> cover.1763537007.git.zhengqi.arch@bytedance.com/
>>
>>>>
>>>>>
>>>>> 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
>>
>> make sense.
>>
>>>
>>> (a) Would we want to make it configurable (why?)
>>
>> No, it was just out of caution before.
>>
>>> (b) Do we really care about SMP (why?)
>>
>> No. Simply because the following situation is impossible to occur:
>>
>> pte_offset_map
>> traversing the PTE page table
>>
>> <preemption or hardirq>
>>
>> call madvise(MADV_DONTNEED)
>>
>> so there's no need to free PTE page via RCU.
>>
>>> (c) Do we want to limit to 64bit (why?)
>>
>> No, just because the profit is greater at 64-BIT.
>
> I was briefly wondering if on 32bit (but maybe also on 64bit with
> configurable user page table levels?) we could have the scenario that we
> only have two page table levels.
>
> So reclaiming the PMD level (corresponding to the highest level) would
reclaiming the PMD level? The PT_RECLAIM only reclaim PTE pages, not PMD
pages, am I misunderstanding something?
> be impossible. But for that to happen one would have to discard the
> whole address range through MADV_DONTNEED (impossible I guess) :)
>
On 19.11.25 13:13, Qi Zheng wrote:
>
>
> On 11/19/25 7:35 PM, David Hildenbrand (Red Hat) wrote:
>> On 19.11.25 12:02, Qi Zheng wrote:
>>> Hi David,
>>>
>>> On 11/19/25 6:19 PM, David Hildenbrand (Red Hat) wrote:
>>>> 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 <zhengqi.arch@bytedance.com>
>>>>>>
>>>>>> 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 <zhengqi.arch@bytedance.com>
>>>>>>> ---
>>>>>>> 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.
>>>
>>> The only difficulty is this:
>>>
>>>>
>>>>>
>>>>> 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.
>>>
>>> in sparc32:
>>>
>>> void pte_free(struct mm_struct *mm, pgtable_t ptep)
>>> {
>>> struct page *page;
>>>
>>> page = pfn_to_page(__nocache_pa((unsigned long)ptep) >>
>>> PAGE_SHIFT);
>>> spin_lock(&mm->page_table_lock);
>>> if (page_ref_dec_return(page) == 1)
>>> pagetable_dtor(page_ptdesc(page));
>>> spin_unlock(&mm->page_table_lock);
>>>
>>> srmmu_free_nocache(ptep, SRMMU_PTE_TABLE_SIZE);
>>> }
>>>
>>> #define __pte_free_tlb(tlb, pte, addr) pte_free((tlb)->mm, pte)
>>>
>>> To enable MMU_GATHER_RCU_TABLE_FREE on sparc32, we need to implement
>>> __tlb_remove_table(), and call the pte_free() above in
>>> __tlb_remove_table().
>>>
>>> However, the __tlb_remove_table() does not have an mm parameter:
>>>
>>> void __tlb_remove_table(void *_table)
>>>
>>> so we need to use another lock instead of mm->page_table_lock.
>>>
>>> I have already sent the v2 [1], and perhaps after that I can enable
>>> PT_RECLAIM on all 32-bit architectures as well.
>>>
>>
>> I guess if we just make it depend on MMU_GATHER_RCU_TABLE_FREE that will
>> be fine.
>>
>>> [1].
>>> https://lore.kernel.org/all/
>>> cover.1763537007.git.zhengqi.arch@bytedance.com/
>>>
>>>>>
>>>>>>
>>>>>> 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
>>>
>>> make sense.
>>>
>>>>
>>>> (a) Would we want to make it configurable (why?)
>>>
>>> No, it was just out of caution before.
>>>
>>>> (b) Do we really care about SMP (why?)
>>>
>>> No. Simply because the following situation is impossible to occur:
>>>
>>> pte_offset_map
>>> traversing the PTE page table
>>>
>>> <preemption or hardirq>
>>>
>>> call madvise(MADV_DONTNEED)
>>>
>>> so there's no need to free PTE page via RCU.
>>>
>>>> (c) Do we want to limit to 64bit (why?)
>>>
>>> No, just because the profit is greater at 64-BIT.
>>
>> I was briefly wondering if on 32bit (but maybe also on 64bit with
>> configurable user page table levels?) we could have the scenario that we
>> only have two page table levels.
>>
>> So reclaiming the PMD level (corresponding to the highest level) would
>
> reclaiming the PMD level? The PT_RECLAIM only reclaim PTE pages, not PMD
> pages, am I misunderstanding something?
Sorry, I looked too much into PMD table sharing the last days :D
You're right, it would work in any case even with only 2 levels of apge
tables.
--
Cheers
David
Hi Qi,
kernel test robot noticed the following build errors:
[auto build test ERROR on deller-parisc/for-next]
[also build test ERROR on uml/next tip/x86/core akpm-mm/mm-everything linus/master v6.18-rc5 next-20251114]
[cannot apply to uml/fixes vgupta-arc/for-next vgupta-arc/for-curr]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Qi-Zheng/alpha-mm-enable-MMU_GATHER_RCU_TABLE_FREE/20251114-191543
base: https://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git for-next
patch link: https://lore.kernel.org/r/0a4d1e6f0bf299cafd1fc624f965bd1ca542cea8.1763117269.git.zhengqi.arch%40bytedance.com
patch subject: [PATCH 7/7] mm: make PT_RECLAIM depend on MMU_GATHER_RCU_TABLE_FREE && 64BIT
config: arm64-randconfig-002-20251115 (https://download.01.org/0day-ci/archive/20251115/202511150832.iAyO0SAW-lkp@intel.com/config)
compiler: clang version 18.1.8 (https://github.com/llvm/llvm-project 3b5b5c1ec4a3095ab096dd780e84d7ab81f3d7ff)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251115/202511150832.iAyO0SAW-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202511150832.iAyO0SAW-lkp@intel.com/
All errors (new ones prefixed by >>):
>> mm/pt_reclaim.c:31:2: error: call to undeclared function '__pte_free_tlb'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
31 | pte_free_tlb(tlb, pmd_pgtable(pmdval), addr);
| ^
include/asm-generic/tlb.h:731:3: note: expanded from macro 'pte_free_tlb'
731 | __pte_free_tlb(tlb, ptep, address); \
| ^
1 error generated.
vim +/__pte_free_tlb +31 mm/pt_reclaim.c
6375e95f381e3d Qi Zheng 2024-12-04 27
6375e95f381e3d Qi Zheng 2024-12-04 28 void free_pte(struct mm_struct *mm, unsigned long addr, struct mmu_gather *tlb,
6375e95f381e3d Qi Zheng 2024-12-04 29 pmd_t pmdval)
6375e95f381e3d Qi Zheng 2024-12-04 30 {
6375e95f381e3d Qi Zheng 2024-12-04 @31 pte_free_tlb(tlb, pmd_pgtable(pmdval), addr);
6375e95f381e3d Qi Zheng 2024-12-04 32 mm_dec_nr_ptes(mm);
6375e95f381e3d Qi Zheng 2024-12-04 33 }
6375e95f381e3d Qi Zheng 2024-12-04 34
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
Hi Qi,
kernel test robot noticed the following build errors:
[auto build test ERROR on deller-parisc/for-next]
[also build test ERROR on uml/next tip/x86/core akpm-mm/mm-everything linus/master v6.18-rc5 next-20251114]
[cannot apply to uml/fixes vgupta-arc/for-next vgupta-arc/for-curr]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Qi-Zheng/alpha-mm-enable-MMU_GATHER_RCU_TABLE_FREE/20251114-191543
base: https://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git for-next
patch link: https://lore.kernel.org/r/0a4d1e6f0bf299cafd1fc624f965bd1ca542cea8.1763117269.git.zhengqi.arch%40bytedance.com
patch subject: [PATCH 7/7] mm: make PT_RECLAIM depend on MMU_GATHER_RCU_TABLE_FREE && 64BIT
config: arm64-randconfig-004-20251115 (https://download.01.org/0day-ci/archive/20251115/202511150845.XqOxPJxe-lkp@intel.com/config)
compiler: aarch64-linux-gcc (GCC) 8.5.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251115/202511150845.XqOxPJxe-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202511150845.XqOxPJxe-lkp@intel.com/
All errors (new ones prefixed by >>):
In file included from mm/pt_reclaim.c:3:
mm/pt_reclaim.c: In function 'free_pte':
>> include/asm-generic/tlb.h:731:3: error: implicit declaration of function '__pte_free_tlb'; did you mean 'pte_free_tlb'? [-Werror=implicit-function-declaration]
__pte_free_tlb(tlb, ptep, address); \
^~~~~~~~~~~~~~
mm/pt_reclaim.c:31:2: note: in expansion of macro 'pte_free_tlb'
pte_free_tlb(tlb, pmd_pgtable(pmdval), addr);
^~~~~~~~~~~~
cc1: some warnings being treated as errors
vim +731 include/asm-generic/tlb.h
a00cc7d9dd93d6 Matthew Wilcox 2017-02-24 701
a00cc7d9dd93d6 Matthew Wilcox 2017-02-24 702 #define tlb_remove_pud_tlb_entry(tlb, pudp, address) \
a00cc7d9dd93d6 Matthew Wilcox 2017-02-24 703 do { \
2631ed00b04988 Peter Zijlstra (Intel 2020-06-25 704) tlb_flush_pud_range(tlb, address, HPAGE_PUD_SIZE); \
a00cc7d9dd93d6 Matthew Wilcox 2017-02-24 705 __tlb_remove_pud_tlb_entry(tlb, pudp, address); \
a00cc7d9dd93d6 Matthew Wilcox 2017-02-24 706 } while (0)
a00cc7d9dd93d6 Matthew Wilcox 2017-02-24 707
b5bc66b7131087 Aneesh Kumar K.V 2016-12-12 708 /*
b5bc66b7131087 Aneesh Kumar K.V 2016-12-12 709 * For things like page tables caches (ie caching addresses "inside" the
b5bc66b7131087 Aneesh Kumar K.V 2016-12-12 710 * page tables, like x86 does), for legacy reasons, flushing an
b5bc66b7131087 Aneesh Kumar K.V 2016-12-12 711 * individual page had better flush the page table caches behind it. This
b5bc66b7131087 Aneesh Kumar K.V 2016-12-12 712 * is definitely how x86 works, for example. And if you have an
b5bc66b7131087 Aneesh Kumar K.V 2016-12-12 713 * architected non-legacy page table cache (which I'm not aware of
b5bc66b7131087 Aneesh Kumar K.V 2016-12-12 714 * anybody actually doing), you're going to have some architecturally
b5bc66b7131087 Aneesh Kumar K.V 2016-12-12 715 * explicit flushing for that, likely *separate* from a regular TLB entry
b5bc66b7131087 Aneesh Kumar K.V 2016-12-12 716 * flush, and thus you'd need more than just some range expansion..
b5bc66b7131087 Aneesh Kumar K.V 2016-12-12 717 *
b5bc66b7131087 Aneesh Kumar K.V 2016-12-12 718 * So if we ever find an architecture
b5bc66b7131087 Aneesh Kumar K.V 2016-12-12 719 * that would want something that odd, I think it is up to that
b5bc66b7131087 Aneesh Kumar K.V 2016-12-12 720 * architecture to do its own odd thing, not cause pain for others
b5bc66b7131087 Aneesh Kumar K.V 2016-12-12 721 * http://lkml.kernel.org/r/CA+55aFzBggoXtNXQeng5d_mRoDnaMBE5Y+URs+PHR67nUpMtaw@mail.gmail.com
b5bc66b7131087 Aneesh Kumar K.V 2016-12-12 722 *
b5bc66b7131087 Aneesh Kumar K.V 2016-12-12 723 * For now w.r.t page table cache, mark the range_size as PAGE_SIZE
b5bc66b7131087 Aneesh Kumar K.V 2016-12-12 724 */
b5bc66b7131087 Aneesh Kumar K.V 2016-12-12 725
a90744bac57c3c Nicholas Piggin 2018-07-13 726 #ifndef pte_free_tlb
9e1b32caa525cb Benjamin Herrenschmidt 2009-07-22 727 #define pte_free_tlb(tlb, ptep, address) \
^1da177e4c3f41 Linus Torvalds 2005-04-16 728 do { \
2631ed00b04988 Peter Zijlstra (Intel 2020-06-25 729) tlb_flush_pmd_range(tlb, address, PAGE_SIZE); \
22a61c3c4f1379 Peter Zijlstra 2018-08-23 730 tlb->freed_tables = 1; \
9e1b32caa525cb Benjamin Herrenschmidt 2009-07-22 @731 __pte_free_tlb(tlb, ptep, address); \
^1da177e4c3f41 Linus Torvalds 2005-04-16 732 } while (0)
a90744bac57c3c Nicholas Piggin 2018-07-13 733 #endif
^1da177e4c3f41 Linus Torvalds 2005-04-16 734
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
© 2016 - 2026 Red Hat, Inc.