Re: xfs: properly account xfs_buf items as reclaimable

On 8/14/26 2:30 AM, Dave Chinner wrote:
> On Thu, Aug 13, 2026 at 03:40:51PM -0500, Eric Sandeen wrote:
>> It was reported that xfs_buf items are not accounted for as
>> reclaimable,
> 
> Actually, they are:
> 
>         xfs_buf_cache = kmem_cache_create("xfs_buf", sizeof(struct xfs_buf), 0,
>                                          SLAB_HWCACHE_ALIGN |
>>>>>>>                                   SLAB_RECLAIM_ACCOUNT,
>                                          NULL);
> 
> So the xfs_buf items themselves are accounted as reclaimable slab
> objects, and these are what the xfs_buf shrinker itself acts on.
> 
>> and therefore various statistics in /proc/meminfo
>> and /proc/vmstat do not reflect their reclaimable nature as
>> other slab-allocated items with shrinkers would do, which in
>> turn affects the accuracy of stats such as MemAvailable.
>>
>> 2 patches here to add accounting for xfs_bufs allocated via
>> xfs_buf_alloc_kmem() and via xfs_buf_alloc_folio().
> 
> That's accounting for the memory attached to the xfs_buf, not the
> xfs_buf itself. 

Yeah, sorry, I was sloppy/wrong in the cover letter. Tracking the
reclaimable memory attached to the xfs_buf items is the intent
here.

> 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?

>> 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?

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.

Thanks,
-Eric

> Cheers,
> 
> Dave.
>