[PATCH] bcachefs: mark bch_inode_info and bkey_cached as reclaimable

[PATCH] bcachefs: mark bch_inode_info and bkey_cached as reclaimable

[Mikulas Patocka]

Mark these caches as reclaimable, so that available memory is correctly
reported when there is a lot of cached inodes.

Note that more work is needed - you should add __GFP_RECLAIMABLE to some 
of the kmalloc calls, so that they are allocated from the "kmalloc-rcl-*" 
caches.

Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>

---
 fs/bcachefs/btree_key_cache.c |    2 +-
 fs/bcachefs/fs.c              |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

Index: bcachefs/fs/bcachefs/btree_key_cache.c
===================================================================
--- bcachefs.orig/fs/bcachefs/btree_key_cache.c
+++ bcachefs/fs/bcachefs/btree_key_cache.c
@@ -1079,7 +1079,7 @@ void bch2_btree_key_cache_exit(void)
 
 int __init bch2_btree_key_cache_init(void)
 {
-	bch2_key_cache = KMEM_CACHE(bkey_cached, 0);
+	bch2_key_cache = KMEM_CACHE(bkey_cached, SLAB_RECLAIM_ACCOUNT);
 	if (!bch2_key_cache)
 		return -ENOMEM;
 
Index: bcachefs/fs/bcachefs/fs.c
===================================================================
--- bcachefs.orig/fs/bcachefs/fs.c
+++ bcachefs/fs/bcachefs/fs.c
@@ -1926,7 +1926,7 @@ int __init bch2_vfs_init(void)
 {
 	int ret = -ENOMEM;
 
-	bch2_inode_cache = KMEM_CACHE(bch_inode_info, 0);
+	bch2_inode_cache = KMEM_CACHE(bch_inode_info, SLAB_RECLAIM_ACCOUNT);
 	if (!bch2_inode_cache)
 		goto err;
 

Re: [PATCH] bcachefs: mark bch_inode_info and bkey_cached as reclaimable

[Kent Overstreet]

On Thu, Jul 13, 2023 at 06:00:28PM +0200, Mikulas Patocka wrote:
> Mark these caches as reclaimable, so that available memory is correctly
> reported when there is a lot of cached inodes.
> 
> Note that more work is needed - you should add __GFP_RECLAIMABLE to some 
> of the kmalloc calls, so that they are allocated from the "kmalloc-rcl-*" 
> caches.

What's that actualy do? grepping for __GFP_RECLAIMABLE doesn't turn up
much. Is it just about segragating objects based on expected lifetime,
or is there more going on?

Re: [PATCH] bcachefs: mark bch_inode_info and bkey_cached as reclaimable

[Mikulas Patocka]

On Fri, 14 Jul 2023, Kent Overstreet wrote:

> On Thu, Jul 13, 2023 at 06:00:28PM +0200, Mikulas Patocka wrote:
> > Mark these caches as reclaimable, so that available memory is correctly
> > reported when there is a lot of cached inodes.
> > 
> > Note that more work is needed - you should add __GFP_RECLAIMABLE to some 
> > of the kmalloc calls, so that they are allocated from the "kmalloc-rcl-*" 
> > caches.
> 
> What's that actualy do? grepping for __GFP_RECLAIMABLE doesn't turn up
> much. Is it just about segragating objects based on expected lifetime,
> or is there more going on?

If you run the test 558 of the XFS testsuite (with the Darrick's forkbomb 
fix), the "free" command shows that there is large amount of memory in the 
"used" column. That is wrong because the test doesn't allocate much memory 
and it doesn't pin down many inodes simultaneously.

If you mark the slab cache with SLAB_RECLAIM_ACCOUNT, the memory allocated 
from this slab cache will be accounted in the "SReclaimable" bucket in 
/proc/meminfo and the "free" command will report it in the "buff/cache" 
column rather than in the "used" column.

If you use __GFP_RECLAIMABLE on kmalloc, the memory is allocated from the 
"kmalloc-rcl-*" caches and it will be accounted in the "SReclaimable" 
bucket.


When I run that test (with slab_nomerge kernel parameter), "slabtop" shows 
that there is large amount of memory allocated from "bch_inode_info", 
"bkey_cached", "dentry" and "kmalloc-256" slab caches.

"dentry" is already reclaimable. "bch_inode_info" and "bkey_cached" is 
fixed by my patch. I don't know where the "kmalloc-256" allocation is 
coming from, but you should use __GFP_RECLAIMABLE there, so that the 
used-vs-cached memory is properly reported.

Mikulas