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

[Kiryl Shutsemau <kas@kernel.org>]

On Fri, Aug 28, 2026 at 01:40:51AM -0700, Hugh Dickins wrote:
> Do you have a head for smp_mb__ barriers? I'm more anxious that
> I might be missing one or two of those.

I think the release side of PG_lru is missing.

You effectively turn PG_lru into a lock over folio->lru.next.

The acquire side works: test_and_clear_bit() has a return value, so it
is fully ordered.

But there's a problem with release. set_bit() is unordered. You
correctly placed a fence in __folio_add_lru(), but every other
folio_set_lru() is problematic.

For instance:

	CPU0 				CPU1
folio_batch_move_lru()		folio_batch_move_lru()
  lru_add_del_folio()
    lru.next = LIST_POISON1
  lruvec lock
    list_add()
  /* no barrier */
  set_bit(PG_lru)
				  folio_try_get() == true
				  folio_test_clear_lru() == true
				  lru_next == stale BATCHED ???
  lruvec unlock

If CPU1 sees a stale BATCHED, lru_add_del_folio() returns true without
doing the list_del() or the NR_LRU_BASE accounting, and CPU1 then goes
on to lruvec_add_folio() a folio that is already on a list.

I think we need to have a helper that would set PG_lru and enforce
release semantics.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov