Re: [PATCH 4/4] xfs: don't decrement the buffer LRU count for in-use buffers

[Brian Foster <bfoster@redhat.com>]

On Wed, Mar 18, 2026 at 09:06:42AM +1100, Dave Chinner wrote:
> On Tue, Mar 17, 2026 at 02:40:55PM +0100, Christoph Hellwig wrote:
> > XFS buffers are added to the LRU when they are unused, but are only
> > removed from the LRU lazily when the LRU list scan finds a used buffer.
> > So far this only happen when the LRU counter hits 0, which is suboptimal
> > as buffers that were added to the LRU, but are in use again still consume
> > LRU scanning resources and are aged while actually in use.
> > 
> > Fix this by checking for in-use buffers and removing the from the LRU
> > before decrementing the LRU counter.
> 
> So I wondered why you put the "in use" check where you did a couple
> of patches ago - it didn't make a lot of sense to me because 'in use
> buffers' typically reset the lru count to their maximum at the same
> time they lookup, lock and take a reference to the buffer. The the
> lock and reference are dropped at the same time when we are done
> with the buffer, so it never made sense to decrement the LRU count
> whilst buffers are locked and referenced...
> 
> Can you just fold this back into the original patch that introduces
> this check?
> 

I explicitly asked Christoph to split this out in an earlier version
because it unnecessarily combines logical changes. The in-use check in
the first patch has nothing to do with how LRU references are tracked or
set, but rather exists because the LRU itself no longer has a hold on
the buffer. Therefore it cannot maintain its own hold while a used
buffer may go on to sit on the dispose list for some period of time.
Instead it has to either free the buffer or not, so the in-use check
leaves the fate of the buffer to the holder(s).

AFAICT this is effectively similar to how existing code works. Whereas
this patch changes how the LRU refcount is managed by always removing
in-use buffers. Note that I'm not arguing whether current behavior makes
sense, just that it's a change in behavior because regardless of whether
holders reset b_lru_ref, nothing totally prevents an LRU resident buffer
from cycling out while in use. This makes it easier to separate
functional rework from buffer LRU behavior change on the off chance that
this leads to an issue down the road and somebody needs to bisect
through these changes.

Brian

> -Dave.
> -- 
> Dave Chinner
> dgc@kernel.org
>