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

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