Re: [PATCH v2 07/26] mm/fbatch: LRU_NEXT_ACTIVATE bit to optimize folio_activate()

[Hugh Dickins]

On Sat, 12 Sep 2026, Hugh Dickins wrote:
...
> I have kept the address for debugging, and do put it to some use in
> the paranoid vmstats patch 27/26. On 32-bit, with 4-byte pointers,
> this LRU_NEXT_ACTIVATE bit does then leave one pointer covering two
> adjacent entries, when it's deciding whether the folio points back
> to this lru_add entry. Is it possible for two adjacent entries to
> hold the same folio (and so perhaps miscount the stat)? Yes, it is
> possible (if that folio is freed and reused and readded immediately);
> but so unlikely that it's of no importance when gathering stats.

It doesn't matter at all, it doesn't affect the choices made here,
but I do want to correct my estimation of the likelihood of identical
adjacent entries. Perhaps the most common occurrence would be, not
when freed+reused+readded, but when isolate_migratepages_block() does
that little lru_add_del_folio() + folio_add_lru() dance. It could be
that the entry it "deletes" (by breaking the linkage from folio to
fbatch) is the one most recently added to that fbatch, then
folio_add_lru() will fill the next slot with that same folio.

Hugh