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
