Re: [PATCH 00/25] mm/fbatch: drain lru_add_drain() and _all()

["David Hildenbrand (Arm)" <david@kernel.org>]

On 8/24/26 15:49, Hugh Dickins wrote:
> This series was prompted by lru_add_drain_all() appearing in watchdog
> backtraces: not to blame, but blocked on an unresponsive CPU to run
> its workqueue. lru_add_drain_all() is a heavyweight operation, which
> we often hope to avoid by a much lighter lru_add_drain(); but even
> those local drains can aggravate the lruvec lock contention which
> per-cpu fbatches are intended to ease.
> 
> Now let the folios on the lru_add and other per-cpu fbatches remain
> there, isolatable, with PG_lru set and refcount unraised, just like
> when on an actual LRU. Then many calls to lru_add_drain() and _all()
> can be removed.
> 
> It's something I've wanted to do for years, tried several times, but
> only hit on a good way to do it a few weeks ago: now it's uncomfortable
> to watch others wrestling with the drainage, while I'm sitting on this.
> 
> The key idea came from the "if (!folio_test_clear_lru(folio)) continue;".
> If we don't mind missing to take an action on rare occasions, then maybe
> we won't mind taking an action on the wrong folio on rare occasions, so
> long as it is a folio consenting to PG_lru rules.
> 
> No new locking, but relies on folio_try_get() and  folio_test_clear_lru()
> even on the lru_add fbatch; with use of bits not set in aligned pointers,
> and some try_cmpxchg()ing.  Speculative references to folios are already
> accepted: this adds another source of them.

Sounds very interesting. Thanks for looking into that, LRU caches are a big pain.

> 
> Performance? You (and the bots) tell me. I'm considering this as a
> cleanup, to make life easier for developers. I expect that some loads
> will show improvement, but also expect some disappointments (perhaps
> I go too far against lru_cache_disable()? or not far enough).
> 
> The timing is not so good: middle of a merge window is not a great
> time to present new work; but I hope to be taking three weeks off in
> two weeks time, so best to get this out in the open early, while I can
> respond.

I'll be out myself next week. And I'm sure my inbox will be even more of a mess
than it is right now when I return.

> If it's welcome in principle for 7.4, but too many changes
> are demanded, maybe someone else can step up to shepherd it through.
I'm certainly interested, my workload is the limiting factor ;)

-- 
Cheers,

David