Re: [PATCH] mm: synchronize with PTE table reclaim for all folio sizes

[Baolin Wang <baolin.wang@linux.alibaba.com>]

On 11/5/26 7:37 PM, Pedro Falcato wrote:
> On Thu, Nov 05, 2026 at 10:56:28AM +0800, Baolin Wang wrote:
>> Similar to commit 243cf1f67b36 ("mm: memory: fix truncation removing mapped
>> folios"), the '!pmd_present()' check in page_vma_mapped_walk() can also race
>> with concurrent page table reclamation via zap_empty_pte_table().
>>
>> page_vma_mapped_walk() is used by many functions including try_to_unmap(),
>> try_to_migrate(), folio_mkclean(), pfn_mkclean_range(), remove_migration_ptes(),
>> page_mapped_in_vma(), and mapping_wrprotect_range(). Except for try_to_unmap()
>> and try_to_migrate(), the other callers do not perform post-walk accounting
>> checks, so the race has no observable impact on them.
>>
>> For migration, the race can cause unnecessary retries. For reclaim via
>> try_to_unmap(), the race can cause failure to reclaim a folio that is in
>> fact already unmapped (as shown below), which may lead to unexpected OOM
>> or increased refaults.
> 
> This is very handwavy. Do you have numbers? Does this actually make sense?

This is hard to measure in practice. But in theory, if we can't reclaim 
cold large folios that are actually unmapped due to the racy checks, it 
could cause cold/hot inversion (e.g., in MGLRU) and increase refaults. 
In extreme cases, failing to reclaim unmapped large folios could even 
cause OOM.