xfs: properly account xfs_buf items as reclaimable

xfs: properly account xfs_buf items as reclaimable

[Eric Sandeen]

It was reported that xfs_buf items are not accounted for as
reclaimable, 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().

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've cc:d linux-mm just because i think this is the first
user of NR_KERNEL_MISC_RECLAIMABLE in the tree?

Thanks,
-Eric

[PATCH 1/2] xfs: mark kmalloc'd xfs_buf items as __GFP_RECLAIMABLE

[Eric Sandeen]

xfs_bufs have a shrinker and are therefore reclaimable; mark
them as such in the kmalloc path, so that they are accounted
for in this way.

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
---
 fs/xfs/xfs_buf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/xfs/xfs_buf.c b/fs/xfs/xfs_buf.c
index 48d7dfd3e15f..2e00a33ebb62 100644
--- a/fs/xfs/xfs_buf.c
+++ b/fs/xfs/xfs_buf.c
@@ -145,7 +145,7 @@ xfs_buf_alloc_kmem(
 	ASSERT(is_power_of_2(size));
 	ASSERT(size < PAGE_SIZE);
 
-	bp->b_addr = kmalloc(size, gfp_mask);
+	bp->b_addr = kmalloc(size, gfp_mask | __GFP_RECLAIMABLE);
 	if (!bp->b_addr)
 		return -ENOMEM;
 
-- 
2.55.0

[PATCH 2/2] xfs: count folio alloc'd xfs_buf items in NR_KERNEL_MISC_RECLAIMABLE

[Eric Sandeen]

xfs_buf allocations via xfs_buf_alloc_folio are actually reclaimable,
but are not accounted for as such. NR_KERNEL_MISC_RECLAIMABLE seems
made for this purpose, although AFAICT there are no users today.

To achieve this, add a new flag _XBF_PAGES to track what we have
allocated this way, increment the NR_KERNEL_MISC_RECLAIMABLE
count when we do, and then do the reverse when they are freed.

These allocations now show up under nr_kernel_misc_reclaimable in
/proc/vmstat when allocations are active, which in turn makes
MemAvailable more accurate in /proc/meminfo.

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
---
 fs/xfs/xfs_buf.c | 16 +++++++++++++---
 fs/xfs/xfs_buf.h |  2 ++
 2 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/fs/xfs/xfs_buf.c b/fs/xfs/xfs_buf.c
index 2e00a33ebb62..0a853ec361d0 100644
--- a/fs/xfs/xfs_buf.c
+++ b/fs/xfs/xfs_buf.c
@@ -114,8 +114,15 @@ xfs_buf_free(
 		vfree(bp->b_addr);
 	else if (bp->b_flags & _XBF_KMEM)
 		kfree(bp->b_addr);
-	else if (bp->b_addr)
-		folio_put(virt_to_folio(bp->b_addr));
+	else if (bp->b_addr) {
+		struct folio *folio = virt_to_folio(bp->b_addr);
+
+		if (bp->b_flags & _XBF_PAGES)
+			mod_node_page_state(folio_pgdat(folio),
+					NR_KERNEL_MISC_RECLAIMABLE,
+					-folio_nr_pages(folio));
+		folio_put(folio);
+	}
 
 	call_rcu(&bp->b_rcu, xfs_buf_free_callback);
 }
@@ -132,6 +139,9 @@ xfs_buf_alloc_folio(
 	if (!folio)
 		return -ENOMEM;
 	bp->b_addr = folio_address(folio);
+	bp->b_flags |= _XBF_PAGES;
+	mod_node_page_state(folio_pgdat(folio), NR_KERNEL_MISC_RECLAIMABLE,
+			folio_nr_pages(folio));
 	trace_xfs_buf_backing_folio(bp, _RET_IP_);
 	return 0;
 }
@@ -427,7 +437,7 @@ xfs_buf_find_lock(
 			return -ENOENT;
 		}
 		ASSERT((bp->b_flags & _XBF_DELWRI_Q) == 0);
-		bp->b_flags &= _XBF_KMEM;
+		bp->b_flags &= (_XBF_PAGES | _XBF_KMEM);
 		bp->b_ops = NULL;
 	}
 	return 0;
diff --git a/fs/xfs/xfs_buf.h b/fs/xfs/xfs_buf.h
index 79cc9c3f0254..ba7bfafe67b6 100644
--- a/fs/xfs/xfs_buf.h
+++ b/fs/xfs/xfs_buf.h
@@ -38,6 +38,7 @@ struct xfs_buf;
 #define _XBF_LOGRECOVERY (1u << 18)/* log recovery buffer */
 
 /* flags used only internally */
+#define _XBF_PAGES	 (1u << 20)/* backed by folio/page allocator */
 #define _XBF_KMEM	 (1u << 21)/* backed by heap memory */
 #define _XBF_DELWRI_Q	 (1u << 22)/* buffer on a delwri queue */
 
@@ -62,6 +63,7 @@ typedef unsigned int xfs_buf_flags_t;
 	{ XBF_STALE,		"STALE" }, \
 	{ XBF_WRITE_FAIL,	"WRITE_FAIL" }, \
 	{ _XBF_LOGRECOVERY,	"LOG_RECOVERY" }, \
+	{ _XBF_PAGES,		"PAGES" }, \
 	{ _XBF_KMEM,		"KMEM" }, \
 	{ _XBF_DELWRI_Q,	"DELWRI_Q" }, \
 	/* The following interface flags should never be set */ \
-- 
2.55.0

Re: [PATCH 1/2] xfs: mark kmalloc'd xfs_buf items as __GFP_RECLAIMABLE

[Christoph Hellwig]

On Thu, Aug 13, 2026 at 03:40:52PM -0500, Eric Sandeen wrote:
> xfs_bufs have a shrinker and are therefore reclaimable; mark
> them as such in the kmalloc path, so that they are accounted
> for in this way.

You can use up all 73 characters for your commit log :)

Otherwise looks fine:

Reviewed-by: Christoph Hellwig <hch@lst.de>

Re: [PATCH 2/2] xfs: count folio alloc'd xfs_buf items in NR_KERNEL_MISC_RECLAIMABLE

[Christoph Hellwig]

On Thu, Aug 13, 2026 at 03:40:53PM -0500, Eric Sandeen wrote:
> xfs_buf allocations via xfs_buf_alloc_folio are actually reclaimable,
> but are not accounted for as such. NR_KERNEL_MISC_RECLAIMABLE seems
> made for this purpose, although AFAICT there are no users today.
> 
> To achieve this, add a new flag _XBF_PAGES to track what we have
> allocated this way, increment the NR_KERNEL_MISC_RECLAIMABLE
> count when we do, and then do the reverse when they are freed.

I don't see why we'd need the flag.  All buffers are either allocated
using vmalloc, kmalloc or as folios.  So it should always be set for
folio allocations (and is misnamed since it now covers folios as well).

> 
> These allocations now show up under nr_kernel_misc_reclaimable in
> /proc/vmstat when allocations are active, which in turn makes
> MemAvailable more accurate in /proc/meminfo.

Adding linux-mm and a few people that touched this counter for
opinions.  I guess the counter is only for full folios, and we
should not set it for the small than page kmalloc allocations?
But even with that, why not set it for the vmalloc allocations?

> 
> Signed-off-by: Eric Sandeen <sandeen@redhat.com>
> ---
>  fs/xfs/xfs_buf.c | 16 +++++++++++++---
>  fs/xfs/xfs_buf.h |  2 ++
>  2 files changed, 15 insertions(+), 3 deletions(-)
> 
> diff --git a/fs/xfs/xfs_buf.c b/fs/xfs/xfs_buf.c
> index 2e00a33ebb62..0a853ec361d0 100644
> --- a/fs/xfs/xfs_buf.c
> +++ b/fs/xfs/xfs_buf.c
> @@ -114,8 +114,15 @@ xfs_buf_free(
>  		vfree(bp->b_addr);
>  	else if (bp->b_flags & _XBF_KMEM)
>  		kfree(bp->b_addr);
> -	else if (bp->b_addr)
> -		folio_put(virt_to_folio(bp->b_addr));
> +	else if (bp->b_addr) {
> +		struct folio *folio = virt_to_folio(bp->b_addr);
> +
> +		if (bp->b_flags & _XBF_PAGES)
> +			mod_node_page_state(folio_pgdat(folio),
> +					NR_KERNEL_MISC_RECLAIMABLE,
> +					-folio_nr_pages(folio));
> +		folio_put(folio);
> +	}
>  
>  	call_rcu(&bp->b_rcu, xfs_buf_free_callback);
>  }
> @@ -132,6 +139,9 @@ xfs_buf_alloc_folio(
>  	if (!folio)
>  		return -ENOMEM;
>  	bp->b_addr = folio_address(folio);
> +	bp->b_flags |= _XBF_PAGES;
> +	mod_node_page_state(folio_pgdat(folio), NR_KERNEL_MISC_RECLAIMABLE,
> +			folio_nr_pages(folio));
>  	trace_xfs_buf_backing_folio(bp, _RET_IP_);
>  	return 0;
>  }
> @@ -427,7 +437,7 @@ xfs_buf_find_lock(
>  			return -ENOENT;
>  		}
>  		ASSERT((bp->b_flags & _XBF_DELWRI_Q) == 0);
> -		bp->b_flags &= _XBF_KMEM;
> +		bp->b_flags &= (_XBF_PAGES | _XBF_KMEM);
>  		bp->b_ops = NULL;
>  	}
>  	return 0;
> diff --git a/fs/xfs/xfs_buf.h b/fs/xfs/xfs_buf.h
> index 79cc9c3f0254..ba7bfafe67b6 100644
> --- a/fs/xfs/xfs_buf.h
> +++ b/fs/xfs/xfs_buf.h
> @@ -38,6 +38,7 @@ struct xfs_buf;
>  #define _XBF_LOGRECOVERY (1u << 18)/* log recovery buffer */
>  
>  /* flags used only internally */
> +#define _XBF_PAGES	 (1u << 20)/* backed by folio/page allocator */
>  #define _XBF_KMEM	 (1u << 21)/* backed by heap memory */
>  #define _XBF_DELWRI_Q	 (1u << 22)/* buffer on a delwri queue */
>  
> @@ -62,6 +63,7 @@ typedef unsigned int xfs_buf_flags_t;
>  	{ XBF_STALE,		"STALE" }, \
>  	{ XBF_WRITE_FAIL,	"WRITE_FAIL" }, \
>  	{ _XBF_LOGRECOVERY,	"LOG_RECOVERY" }, \
> +	{ _XBF_PAGES,		"PAGES" }, \
>  	{ _XBF_KMEM,		"KMEM" }, \
>  	{ _XBF_DELWRI_Q,	"DELWRI_Q" }, \
>  	/* The following interface flags should never be set */ \
> -- 
> 2.55.0
> 
> 
---end quoted text---

Re: xfs: properly account xfs_buf items as reclaimable

[Dave Chinner]

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

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

Cheers,

Dave.

-- 
Dave Chinner
dgc@kernel.org

Re: [PATCH 2/2] xfs: count folio alloc'd xfs_buf items in NR_KERNEL_MISC_RECLAIMABLE

[Eric Sandeen]

On 8/14/26 2:25 AM, Christoph Hellwig wrote:
> On Thu, Aug 13, 2026 at 03:40:53PM -0500, Eric Sandeen wrote:
>> xfs_buf allocations via xfs_buf_alloc_folio are actually reclaimable,
>> but are not accounted for as such. NR_KERNEL_MISC_RECLAIMABLE seems
>> made for this purpose, although AFAICT there are no users today.
>>
>> To achieve this, add a new flag _XBF_PAGES to track what we have
>> allocated this way, increment the NR_KERNEL_MISC_RECLAIMABLE
>> count when we do, and then do the reverse when they are freed.
> 
> I don't see why we'd need the flag.  All buffers are either allocated
> using vmalloc, kmalloc or as folios.  So it should always be set for
> folio allocations (and is misnamed since it now covers folios as well).

Hmm ok I think you're right. And using PAGES is misnamed, yeah.
>>
>> These allocations now show up under nr_kernel_misc_reclaimable in
>> /proc/vmstat when allocations are active, which in turn makes
>> MemAvailable more accurate in /proc/meminfo.
> 
> Adding linux-mm and a few people that touched this counter for
> opinions.  I guess the counter is only for full folios, and we
> should not set it for the small than page kmalloc allocations?
> But even with that, why not set it for the vmalloc allocations?
I hesitated based on node accounting but dchinner sounded unconcerned:
"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."

I fixed those up but won't resend just yet, thanks.

And I promise to use more columns next time ;)

-Eric

Re: xfs: properly account xfs_buf items as reclaimable

[Eric Sandeen]

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

Re: xfs: properly account xfs_buf items as reclaimable

[Dave Chinner]

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
dgc@kernel.org