From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9AD91C433F5 for ; Mon, 21 Feb 2022 01:55:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 051296B0072; Sun, 20 Feb 2022 20:55:34 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 00A946B0073; Sun, 20 Feb 2022 20:55:33 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E0A206B0074; Sun, 20 Feb 2022 20:55:33 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.27]) by kanga.kvack.org (Postfix) with ESMTP id CE6126B0072 for ; Sun, 20 Feb 2022 20:55:33 -0500 (EST) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 9E06E21C19 for ; Mon, 21 Feb 2022 01:55:33 +0000 (UTC) X-FDA: 79165120146.05.E9327FA Received: from smtpbguseast3.qq.com (smtpbguseast3.qq.com [54.243.244.52]) by imf29.hostedemail.com (Postfix) with ESMTP id 39673120002 for ; Mon, 21 Feb 2022 01:55:32 +0000 (UTC) X-QQ-mid: bizesmtp72t1645408521t1ap8c66 Received: from [10.4.23.188] (unknown [58.240.82.166]) by bizesmtp.qq.com (ESMTP) with id ; Mon, 21 Feb 2022 09:55:18 +0800 (CST) X-QQ-SSF: 01400000002000B0F000000A0000000 X-QQ-FEAT: Mzskoac49OhWOi2RkK8bwf1V7Yi1+ZUnx/rgOSpqH0M+yQnAMWpFGUY1cCyKR 5jUL4dCLMOQ/XgvEEPobT5KxHupTNWt+zVfRc6uyI7IUWrLKhPLyv71RAlkgQ+IkA92njGH 0j/hiAhyW8o6+lLQ+7KgyumAhenhfnLrQugcp/V2WuLtBeSCrK+oZkWku/IeIYiq17Exnsv 7zTMFAa2Vm0ykWlNiot6+3ihwGeFuOVYlWsv+jAhzGyCvzdkdINR/qX1w5QF4UvECnvL96J lL42T+WWlqyVQX/rpyrKnRf/XSK9qQryIwiFGL1Qt/NsWEcy28Oni8Cq8i/C1H2Vu26jjbJ IX+hykoCczO/4U6AjiNs8my+cM3zNdMpB3olvJF X-QQ-GoodBg: 1 Message-ID: +A91DCEC7F1CD1A10 Date: Mon, 21 Feb 2022 09:55:18 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Subject: Re: [PATCH 10/11] fs/drop_caches: move drop_caches sysctls to its own file To: Matthew Wilcox 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, sujiaxun@uniontech.com References: <20220220060626.15885-1-tangmeng@uniontech.com> From: tangmeng In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-QQ-SENDSIZE: 520 Feedback-ID: bizesmtp:uniontech.com:qybgforeign:qybgforeign6 X-QQ-Bgrelay: 1 X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 39673120002 X-Stat-Signature: n5at4365hzgo3acrn66gd4ah5oxnzodm Authentication-Results: imf29.hostedemail.com; dkim=none; spf=pass (imf29.hostedemail.com: domain of tangmeng@uniontech.com designates 54.243.244.52 as permitted sender) smtp.mailfrom=tangmeng@uniontech.com; dmarc=none X-Rspam-User: X-HE-Tag: 1645408532-102066 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 2022/2/20 19:40, Matthew Wilcox wrote: > 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. Thanks for the heads up! I will delete 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? > I think it is obviously the right thing that we need to do. However, many submissions have been commited which registers an array before, I think that having a register_sysctl_one() which registers exactly one ctl_table should submit in a separate submission, rather than modify it this time.