Re: [PATCH v4 5/5] mm/vmscan: flush TLB for every 31 folios evictions

[Zhang Peng]

On Wed, Jun 17, 2026 at 02:47:36PM +0200, David Hildenbrand wrote:
> Two tabs. But this is starting to look a bit messy. Could a helper
> struct be used to reduce the parameter count to something readable?

Yeah, 7 args is too many.  For v5 I'll bundle the plumbing into a
small struct.

> That looks rather hacky. You reinit the batch to then traverse the
> batch? There must be a cleaner way.

It works because reinit only zeros ->nr and ->i, the folios[] array
stays intact — saved count lets you walk it while folio_batch_add()
rebuilds.  But I agree it's too subtle. Maybe I will use a local temp
array insteand.

> Took me a second to understand why exactly you test for these
> properties. Can you add a comment how these check here mimic what
> we checked earlier, before dropping the lock?

Will do.  The three checks correspond to what shrink_folio_list() did
before the unlock: writeback may have started, swapin may have
remapped the folio, a GUP may have pinned it.  Anything that fails
goes back via ret_folios.

> So, IIUC, what could have happened after dropping the folio lock is
> that someone would have remapped the folio to user space?
>
> Either from the pagecache or from the swap PTE -> swapcache.
>
> From there, it could have gotten pinned through the page tables.
>
> Is that correct?

Yes, exactly.  A swapin (or a page cache lookup for file-backed)
can find the folio while it's unlocked, remap it into some process's
page tables, and from there a GUP — O_DIRECT, vmsplice, RDMA, etc. —
can pin it.  That's precisely why pageout_batch() rechecks mapped
and dma_pinned before doing the TLB flush and writeout.  Any folio
that got remapped or pinned in the window goes back via ret_folios
instead.

> What would happen if page migration finds the folio, locks it and
> wants to migrate it?

Migration can't find it.  The folio is off the LRU (isolated) and
out of page tables (unmapped) — migration's two entry points.
Compaction walks PFNs but skips !PageLRU pages.NUMA hinting faults
walk page tables and won't find a folio with no PTEs.