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

[Hugh Dickins <hughd@google.com>]

On Mon, 31 Aug 2026, Kiryl Shutsemau wrote:
> 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.

Thank you very much for this, Kiryl: it helps me considerably.
But I have to cool myself down close to absolute zero to think
about these things, and can only manage that occasionally.

I've nothing useful to say yet. I believe I understand you, and in
particular your last sentence, which I take as an observation that
clear_bit_unlock() is well-established, but what we want is
set_bit_unlock(), perhaps better named set_bit_release().

Of course I'm not competent to add that to N architectures, most of
them unfamiliar to me.  So I'm looking for a reasonable compromise,
to minimize the additional overhead needed for correctness here,
just using what we have already have (test_and_set, smp_mb__).

When I read up further on KCSAN, I saw that it intends to catch
such ordering issues, and I'm hoping it will help. There are KCSAN
reports with "lru" in, even without my changes, but more with my
changes than without: I'll look to cut those down.

Thanks,
Hugh