From: Matthew Wilcox <willy@infradead.org>
To: tangmeng <tangmeng@uniontech.com>
Cc: viro@zeniv.linux.org.uk, akpm@linux-foundation.org,
mcgrof@kernel.org, keescook@chromium.org, yzaikin@google.com,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
linux-fsdevel@vger.kernel.org, nizhen@uniontech.com,
zhanglianjie@uniontech.com, nixiaoming@huawei.com
Subject: Re: [PATCH 10/11] fs/drop_caches: move drop_caches sysctls to its own file
Date: Sun, 20 Feb 2022 11:40:01 +0000 [thread overview]
Message-ID: <YhIokWPShGOYh9LK@casper.infradead.org> (raw)
In-Reply-To: <20220220060626.15885-1-tangmeng@uniontech.com>
On Sun, Feb 20, 2022 at 02:06:26PM +0800, tangmeng wrote:
> diff --git a/fs/drop_caches.c b/fs/drop_caches.c
> @@ -75,3 +75,25 @@ int drop_caches_sysctl_handler(struct ctl_table *table, int write,
> }
> return 0;
> }
> +
> +#ifdef CONFIG_SYSCTL
fs/Makefile has:
obj-$(CONFIG_SYSCTL) += drop_caches.o
so we don't need this ifdef.
> +static struct ctl_table vm_drop_caches_table[] = {
> + {
> + .procname = "drop_caches",
> + .data = &sysctl_drop_caches,
> + .maxlen = sizeof(int),
> + .mode = 0200,
> + .proc_handler = drop_caches_sysctl_handler,
> + .extra1 = SYSCTL_ONE,
> + .extra2 = SYSCTL_FOUR,
> + },
> + { }
> +};
Something which slightly concerns me about this sysctl splitup (which
is obviously the right thing to do) is that ctl_table is quite large
(64 bytes per entry) and every array is terminated with an empty one.
In this example, we've gone from 64 bytes to 128 bytes.
Would we be better off having a register_sysctl_one() which
registers exactly one ctl_table, rather than an array? And/or a
register_sysctl_array() which takes an ARRAY_SIZE() of its argument
instead of looking for the NULL terminator?
next prev parent reply other threads:[~2022-02-20 11:40 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-20 6:06 tangmeng
2022-02-20 11:40 ` Matthew Wilcox [this message]
2022-02-21 1:55 ` tangmeng
2022-02-23 0:39 ` Luis Chamberlain
2022-02-23 9:51 ` tangmeng
2022-02-26 21:00 ` Luis Chamberlain
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=YhIokWPShGOYh9LK@casper.infradead.org \
--to=willy@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=keescook@chromium.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mcgrof@kernel.org \
--cc=nixiaoming@huawei.com \
--cc=nizhen@uniontech.com \
--cc=tangmeng@uniontech.com \
--cc=viro@zeniv.linux.org.uk \
--cc=yzaikin@google.com \
--cc=zhanglianjie@uniontech.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