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

[Kairui Song]

On Mon, Sep 7, 2026 at 8:36 PM David Hildenbrand (Arm) <david@xxxxxxxxxx> wrote:
>
> On 8/30/26 17:23, Kairui Song wrote:
> > On Thu, Aug 27, 2026 at 06:36:18PM +0800, David Hildenbrand (Arm) wrote:
> >> On 8/20/26 20:55, Kairui Song via B4 Relay wrote:
> >>> From: Kairui Song <kasong@xxxxxxxxxxx>
> >>>
> >>> Only anon split needs vma info, and only file split needs the filemap
> >>> handling. Move the related code into separate helpers so they are
> >>> genuinely more self-contained.
> >>
> >> This patch seems to do more than that, like relocating the
> >> folio_expected_ref_count check (and duplicating it, which is not so nice).
> >
> > 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 think I can send a v4, the patch should look cleaner after removing
the swap cache behavior change part. A few commits changed a bit, so
it might be worth some attention. Thanks for the review on V3.