Re: [PATCH v3 09/18] mm/huge_memory: move anon_vma and filemap management into split helpers

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

On 9/7/26 19:55, Kairui Song wrote:
> On Mon, Sep 7, 2026 at 8:36 PM David Hildenbrand (Arm) <david@kernel.org> wrote:
>>
>> On 8/30/26 17:23, Kairui Song wrote:
>>>
>>> We can keep it where it is right now, but this patch is moving the
>>> anon_vma_lock_write and i_mmap_lock_read into the two anon / file
>>> helpers seperately, so keeping the folio_expected_ref_count check
>>> outside and before the helper call will cause a potential higher
>>> false positive / negative rate of this check? Leads to unnecessary
>>> call to unmap_folio.
>>>
>>> How about moving the folio_expected_ref_count check into
>>> unmap_folio since the purpose of the ref check is to avoid
>>> unnecessary unmap? No more duplication that way.
>>
>> I think the crucial part (for anon folios) is to also check after we unmapped.
>>
>> See __folio_migrate_mapping(), where we don't do the !folio_ref_freeze() in case
>> we tun into the !mapping scenario.
> 
> If I understand you correctly, I think we are fine as is? The
> folio_expected_ref_count() check here is just a racy check to avoid
> the PMD split for a folio that cannot be split anyway, not a gate.
> 
> The gate is the folio_ref_freeze() immediately after unmap_folio() in
> __folio_freeze_split_anon() (only a local_irq_disable() in between).
> For an unmapped anon folio folio_expected_ref_count() is uses
> folio_swapcache_ref_count(). It might be worth optimizing, but that
> could be done later.
> 
> Or did you mean something else for the anon case?

I thought for anon folios during migration it actually serves the purpose *after
unmap* to detect any remaining GUP references (etc). But I might be wrong. I'll
look at v4.

-- 
Cheers,

David