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

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

On 11/6/26 03:12, Baolin Wang wrote:
> 
> 
> 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.

Yeah, but the question is if it really matters in practice.

I agree that page_mapped_in_vma() should sync properly, but the current impact
might not be as severe.

-- 
Cheers,

David