public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <dgc@kernel.org>
To: Christoph Hellwig <hch@lst.de>
Cc: Carlos Maiolino <cem@kernel.org>,
	Dave Chinner <dchinner@redhat.com>,
	Brian Foster <bfoster@redhat.com>,
	linux-xfs@vger.kernel.org, "Darrick J. Wong" <djwong@kernel.org>
Subject: Re: [PATCH 4/4] xfs: don't decrement the buffer LRU count for in-use buffers
Date: Wed, 18 Mar 2026 09:06:42 +1100	[thread overview]
Message-ID: <abnQcrRk55SEqPu0@dread> (raw)
In-Reply-To: <20260317134110.1691097-5-hch@lst.de>

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?

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

  reply	other threads:[~2026-03-17 22:06 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-17 13:40 buffer cache simplification v5 Christoph Hellwig
2026-03-17 13:40 ` [PATCH 1/4] xfs: don't keep a reference for buffers on the LRU Christoph Hellwig
2026-03-17 21:33   ` Dave Chinner
2026-03-18 14:38     ` Christoph Hellwig
2026-03-18 11:44   ` Brian Foster
2026-03-17 13:40 ` [PATCH 2/4] xfs: use a lockref for the buffer reference count Christoph Hellwig
2026-03-17 21:53   ` Dave Chinner
2026-03-18 14:49     ` Christoph Hellwig
2026-03-17 13:40 ` [PATCH 3/4] xfs: switch (back) to a per-buftarg buffer hash Christoph Hellwig
2026-03-17 22:00   ` Dave Chinner
2026-03-18 12:14   ` Brian Foster
2026-03-17 13:40 ` [PATCH 4/4] xfs: don't decrement the buffer LRU count for in-use buffers Christoph Hellwig
2026-03-17 22:06   ` Dave Chinner [this message]
2026-03-18 11:47     ` Brian Foster
2026-03-18 11:45   ` Brian Foster
  -- strict thread matches above, loose matches on Subject: below --
2026-03-23  7:50 buffer cache simplification v6 Christoph Hellwig
2026-03-23  7:50 ` [PATCH 4/4] xfs: don't decrement the buffer LRU count for in-use buffers Christoph Hellwig
2026-03-23 12:27   ` Brian Foster

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=abnQcrRk55SEqPu0@dread \
    --to=dgc@kernel.org \
    --cc=bfoster@redhat.com \
    --cc=cem@kernel.org \
    --cc=dchinner@redhat.com \
    --cc=djwong@kernel.org \
    --cc=hch@lst.de \
    --cc=linux-xfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox