Re: [PATCH v3 0/3] add support for drop_caches for individual filesystem

[Jan Kara <jack@suse.cz>]

On Tue 03-03-26 10:32:12, yebin (H) wrote:
> On 2026/2/27 16:27, Muchun Song wrote:
> > > On Feb 27, 2026, at 16:17, yebin (H) <yebin10@huawei.com> wrote:
> > > On 2026/2/27 15:45, Muchun Song wrote:
> > > > > On Feb 27, 2026, at 15:32, yebin (H) <yebin10@huawei.com> wrote:
> > > > > On 2026/2/27 14:55, Muchun Song wrote:
> > > > > > > On Feb 27, 2026, at 14:39, yebin (H) <yebin10@huawei.com> wrote:
> > > > > > > On 2026/2/27 11:31, Muchun Song wrote:
> > > > > > > > > On Feb 27, 2026, at 10:55, Ye Bin <yebin@huaweicloud.com> wrote:
> > > > > > > > > 
> > > > > > > > > From: Ye Bin <yebin10@huawei.com>
> > > > > > > > > 
> > > > > > > > > In order to better analyze the issue of file system uninstallation caused
> > > > > > > > > by kernel module opening files, it is necessary to perform dentry recycling
> > > > > > > > > on a single file system. But now, apart from global dentry recycling, it is
> > > > > > > > > not supported to do dentry recycling on a single file system separately.
> > > > > > > > 
> > > > > > > > Would shrinker-debugfs satisfy your needs (See Documentation/admin-guide/mm/shrinker_debugfs.rst)?
> > > > > > > > 
> > > > > > > > Thanks,
> > > > > > > > Muchun
> > > > > > > > 
> > > > > > > Thank you for the reminder. The reclamation of dentries and nodes can meet my needs. However, the reclamation of the page cache alone does not satisfy my requirements. I have reviewed the code of shrinker_debugfs_scan_write() and found that it does not support batch deletion of all dentries/inode for all nodes/memcgs,instead, users need to traverse through them one by one, which is not very convenient. Based on my previous experience, I have always performed dentry/inode reclamation at the file system level.
> > > > > > 
> > > > > > I don't really like that you're implementing another mechanism with duplicate
> > > > > > functionality. If you'd like, you could write a script to iterate through them
> > > > > > and execute it that way—I don't think that would be particularly inconvenient,
> > > > > > would it? If the iteration operation of memcg is indeed quite cumbersome, I
> > > > > > think extending the shrinker debugfs functionality would be more appropriate.
> > > > > > 
> > > > > The shrinker_debugfs can be extended to support node/memcg/fs granularity reclamation, similar to the extended function of echo " 0 - X" > count /echo " - 0 X" > count /echo " - - X" > count. This only solves the problem of reclaiming dentries/inode based on a single file system. However, the page cache reclamation based on a single file system cannot be implemented by using shrinker_debugfs. If the extended function is implemented by shrinker_debugfs, drop_fs_caches can reuse the same interface and maintain the same semantics as drop_caches.
> > > > 
> > > > If the inode is evicted, the page cache is evicted as well. It cannot evict page
> > > > cache alone. Why you want to evict cache alone?
> > > > 
> > > The condition for dentry/inode to be reclaimed is that there are no
> > > references to them. Therefore, relying on inode reclamation for page
> > > cache reclamation has limitations. Additionally, there is currently no
> > 
> > What limit?
> > 
> Perhaps I didn't explain it clearly earlier. What I want to achieve is
> the ability to perform memory reclamation (pagecache/dentry/inode)
> based on a single file system. In the current network environment, when
> troubleshooting issues, I want to control the impact of operations and
> only perform memory reclamation on specific file systems. Therefore,
> some files might be in an occupied state, and relying on dentry/inode
> to reclaim pagecache will not achieve the desired effect. Additionally,
> I have encountered some users who periodically run `drop_caches`,
> mainly to clear the pagecache. If we rely on dentry/inode to release
> resources, there will be issues where the pagecache cannot be fully
> cleared. This level of granularity is actually unnecessary because in
> some scenarios, users know which partitions they use more frequently,
> so they only need to clear the pagecache for specific partitions.

Let me revive this thread :) I agree with Ye Bin - the more interesting
part of this functionality is actually giving userspace a way to
effectively trigger drop_pagecache_sb() only for one superblock and inode
/ dentry shrinkers have no chance to do that. In particular because for
example drop_pagecache_sb() will also discard page cache of currently open
files but the inodes / dentries are used (struct file pins them in memory)
so shrinker doesn't even consider them.

I don't have a strong preference whether the API for triggering page cache
reclaim for one sb will be through /proc/sys/vm/<some_new_file> or through
debugfs (possibly <debugfs>/shrinkers/page_cache or something like that)
but this functionality definitely cannot be achieved by just triggering
some shrinkers.

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR