Re: xfs: properly account xfs_buf items as reclaimable

On Fri, Aug 14, 2026 at 11:07:45AM -0500, Eric Sandeen wrote:
> On 8/14/26 2:30 AM, Dave Chinner wrote:
> > On Thu, Aug 13, 2026 at 03:40:51PM -0500, Eric Sandeen wrote:
> > We don't use the size of that memory for reclaim
> > purposes, hence we haven't ever tracked it. It is, however, fed back
> > into shrinker based memory reclaim via mm_account_reclaimed_pages()
> > in xfs_buf_free() and hence memory reclaim correctly tracks how much
> > memory was released by the xfs_buf shrinker scan, even if the user
> > visible stats don't show it.
> 
> I guess that's the crux of the question: should those stats show it?

Filesystem metadata is often cached on the block device address
space (e.g. anything that uses sb_getblk() like extN and various
other filesystems do) and that shows up as "Buffers" in meminfo.
i.e. cached file data shows up a page cache (i.e. NR_FILE...),
cached metadata shows up as "buffers". 

The XFS buffer cache is caching metadata buffers, but it's not in
the block dev address space like bufferhead based filesystems do so
the nr_blockdev_pages() does not automatically account for it.
Unfortunately, this isn't accounted by a vmstat counter, but by
iterating the list of block device inodes and counting the number of
pages attached to each bdev mapping....

> >> I was not sure how to handle xfs_buf_alloc_vmalloc but I think
> >> that's a relatively rare path, and the above two will capture
> >> the majority of xfs_buf allocations.
> > 
> > I think both folio and vmalloc should be accounted in the same
> > manner - as a number of pages based on the size of the buffer (i.e.
> > same as mm_account_reclaimed_pages() does already). It doesn't
> > matter if it is vmalloc or a high order folio, the amount of memory
> > is the same.  If it gets accounted to the node of the first folio,
> > then it will at least always be consistently accounted, if not
> > always 100% accurate for the vmalloc case.
> 
> OK fair.
> 
> >> I've cc:d linux-mm just because i think this is the first
> >> user of NR_KERNEL_MISC_RECLAIMABLE in the tree?
> > 
> > These are fs buffers - shouldn't they be accounted as something that
> > reports as "cached" or "buffers" in /proc/meminfo? I mean, if you're
> > going to do this to make meminfo/vmstat report the memory usage,
> > shouldn't we make the effort to classify the memory usage correctly
> > for the user?
> 
> I'm not sure. NR_KERNEL_MISC_RECLAIMABLE says it's for
> "reclaimable non-slab kernel pages" and that seemed appropriate for
> this case; they really aren't the same as page cache?

Bufferram is "double accounted" in meminfo output. The folios are
accounted to the bdev page cache, but also to the "buffer" output.
the meinfo code then calculates "cached" as (page cache - swap -
buffers) - i.e. cached file data - so that buffers + cache totals
all the cached filesystem data + metadata....

Yes, XFS buffers don't fit into that, either, because we don't use
the page cache for the bdev buffer cache, but my point is that most
filesystems report cached metadata as "buffers" and users have long
expected "cached" to be the total of cached file data, and buffers
to be the total of cached metadata...

IMO, if we are going to report how much metadata we are caching in
the XFS buffer cache, we should try to make it match all the other
filesystem accounting...

> The commit (b29940c1abd7) that created NR_KERNEL_MISC_RECLAIMABLE
> renamed it from NR_INDIRECTLY_RECLAIMABLE_BYTES, and said it was
> "still useful for accounting direct page allocations (i.e. not slab)
> with a shrinker" so it seemed appropriate but clearly I'm a bit out
> of my depth here.

It would be appropriate if there wasn't already stats that are
supposed to report cached filesystem metadata. I could use the
example of shrinker reclaimed DRM memory pools as an example of a
valid use of NR_KERNEL_MISC_RECLAIMABLE because there is no other
equivalent functionality. However, a few months back they made the
DRM accounting a first class citizen via commit 2232ba9c7931 (mm:
add gpu active/reclaim per-node stat counters (v2)).

And that's kinda my point: if we need to expose the memory usage to
userspace, we should be presenting it the right way - consistent
with other filesystems - rather doing that requires minimal code but
requires all sorts of mental gymnastics for the user to determine
that some of their weird "MISC" memory usage is actually XFS
metadata.

-Dave.
-- 
Dave Chinner
[email protected]