From: Jan Kara <jack@suse.cz>
To: Ye Bin <yebin@huaweicloud.com>
Cc: viro@zeniv.linux.org.uk, brauner@kernel.org, jack@suse.cz,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
yebin10@huawei.com, zhangxiaoxu5@huawei.com
Subject: Re: [PATCH 2/3] sysctl: add support for drop_caches for individual filesystem
Date: Thu, 10 Oct 2024 14:16:07 +0200 [thread overview]
Message-ID: <20241010121607.54ttcmdfmh7ywho7@quack3> (raw)
In-Reply-To: <20241010112543.1609648-3-yebin@huaweicloud.com>
On Thu 10-10-24 19:25:42, Ye Bin 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
I don't quite understand the use case you mention here. Can you explain it
a bit more (that being said I've needed dropping caches for a particular sb
myself a few times for debugging purposes so I generally agree it is a
useful feature).
> 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.
> This feature has usage scenarios in problem localization scenarios.At the
> same time, it also provides users with a slightly fine-grained
> pagecache/entry recycling mechanism.
> This patch supports the recycling of pagecache/entry for individual file
> systems.
>
> Signed-off-by: Ye Bin <yebin10@huawei.com>
> ---
> fs/drop_caches.c | 43 +++++++++++++++++++++++++++++++++++++++++++
> include/linux/mm.h | 2 ++
> kernel/sysctl.c | 9 +++++++++
> 3 files changed, 54 insertions(+)
>
> diff --git a/fs/drop_caches.c b/fs/drop_caches.c
> index d45ef541d848..99d412cf3e52 100644
> --- a/fs/drop_caches.c
> +++ b/fs/drop_caches.c
> @@ -77,3 +77,46 @@ int drop_caches_sysctl_handler(const struct ctl_table *table, int write,
> }
> return 0;
> }
> +
> +int drop_fs_caches_sysctl_handler(const struct ctl_table *table, int write,
> + void *buffer, size_t *length, loff_t *ppos)
> +{
> + unsigned int major, minor;
> + unsigned int ctl;
> + struct super_block *sb;
> + static int stfu;
> +
> + if (!write)
> + return 0;
> +
> + if (sscanf(buffer, "%u:%u:%u", &major, &minor, &ctl) != 3)
> + return -EINVAL;
I think specifying bdev major & minor number is not a great interface these
days. In particular for filesystems which are not bdev based such as NFS. I
think specifying path to some file/dir in the filesystem is nicer and you
can easily resolve that to sb here as well.
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
next prev parent reply other threads:[~2024-10-10 12:16 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-10 11:25 [PATCH 0/3] " Ye Bin
2024-10-10 11:25 ` [PATCH 1/3] vfs: introduce shrink_icache_sb() helper Ye Bin
2024-10-10 12:07 ` Jan Kara
2024-10-10 11:25 ` [PATCH 2/3] sysctl: add support for drop_caches for individual filesystem Ye Bin
2024-10-10 12:16 ` Jan Kara [this message]
2024-10-10 12:44 ` yebin (H)
2024-10-10 13:35 ` Benjamin Coddington
2024-10-10 17:04 ` Jan Kara
2024-10-11 11:44 ` Amir Goldstein
2024-10-14 11:24 ` Jan Kara
2024-10-10 13:48 ` Thomas Weißschuh
2024-10-10 17:17 ` Al Viro
2024-10-10 11:25 ` [PATCH 3/3] Documentation: add instructions for using 'drop_fs_caches sysctl' sysctl Ye Bin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20241010121607.54ttcmdfmh7ywho7@quack3 \
--to=jack@suse.cz \
--cc=brauner@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
--cc=yebin10@huawei.com \
--cc=yebin@huaweicloud.com \
--cc=zhangxiaoxu5@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®