kernel/sysctl.c is a kitchen sink where everyone leaves their dirty
dishes, this makes it very difficult to maintain.
To help with this maintenance let's start by moving sysctls to places
where they actually belong. The proc sysctl maintainers do not want to
know what sysctl knobs you wish to add for your own piece of code, we
just care about the core logic.
All filesystem syctls now get reviewed by fs folks. This commit
follows the commit of fs, move the drop_caches sysctls to its own file,
fs/drop_caches.c.
Signed-off-by: tangmeng <[email protected]>
---
fs/drop_caches.c | 24 ++++++++++++++++++++++--
include/linux/mm.h | 6 ------
kernel/sysctl.c | 9 ---------
3 files changed, 22 insertions(+), 17 deletions(-)
diff --git a/fs/drop_caches.c b/fs/drop_caches.c
index e619c31b6bd9..44f5539dd217 100644
--- a/fs/drop_caches.c
+++ b/fs/drop_caches.c
@@ -13,7 +13,7 @@
#include "internal.h"
/* A global variable is a bit ugly, but it keeps the code simple */
-int sysctl_drop_caches;
+static int sysctl_drop_caches;
static void drop_pagecache_sb(struct super_block *sb, void *unused)
{
@@ -47,7 +47,7 @@ static void drop_pagecache_sb(struct super_block *sb, void *unused)
iput(toput_inode);
}
-int drop_caches_sysctl_handler(struct ctl_table *table, int write,
+static int drop_caches_sysctl_handler(struct ctl_table *table, int write,
void *buffer, size_t *length, loff_t *ppos)
{
int ret;
@@ -75,3 +75,23 @@ int drop_caches_sysctl_handler(struct ctl_table *table, int write,
}
return 0;
}
+
+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,
+ },
+ { }
+};
+
+static __init int vm_drop_caches_sysctls_init(void)
+{
+ register_sysctl_init("vm", vm_drop_caches_table);
+ return 0;
+}
+late_initcall(vm_drop_caches_sysctls_init);
diff --git a/include/linux/mm.h b/include/linux/mm.h
index c3c7cb58c847..775befb2786b 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -3126,12 +3126,6 @@ static inline int in_gate_area(struct mm_struct *mm, unsigned long addr)
extern bool process_shares_mm(struct task_struct *p, struct mm_struct *mm);
-#ifdef CONFIG_SYSCTL
-extern int sysctl_drop_caches;
-int drop_caches_sysctl_handler(struct ctl_table *, int, void *, size_t *,
- loff_t *);
-#endif
-
void drop_slab(void);
#ifndef CONFIG_MMU
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index b51b0b92fdc1..657b7bfe38f6 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -2182,15 +2182,6 @@ static struct ctl_table vm_table[] = {
.mode = 0644,
.proc_handler = lowmem_reserve_ratio_sysctl_handler,
},
- {
- .procname = "drop_caches",
- .data = &sysctl_drop_caches,
- .maxlen = sizeof(int),
- .mode = 0200,
- .proc_handler = drop_caches_sysctl_handler,
- .extra1 = SYSCTL_ONE,
- .extra2 = SYSCTL_FOUR,
- },
#ifdef CONFIG_COMPACTION
{
.procname = "compact_memory",
--
2.20.1
On Mon, Feb 21, 2022 at 02:10:18PM +0800, tangmeng wrote:
> kernel/sysctl.c is a kitchen sink where everyone leaves their dirty
> dishes, this makes it very difficult to maintain.
>
> To help with this maintenance let's start by moving sysctls to places
> where they actually belong. The proc sysctl maintainers do not want to
> know what sysctl knobs you wish to add for your own piece of code, we
> just care about the core logic.
>
> All filesystem syctls now get reviewed by fs folks. This commit
> follows the commit of fs, move the drop_caches sysctls to its own file,
> fs/drop_caches.c.
>
> Signed-off-by: tangmeng <[email protected]>
Thanks but please send a v3 including all the other patches as well
and collecting the Reviewed/Acked-bys, etc. This can be sent *after*
your v3 of the optimization work.
Luis
On Wed, Mar 02, 2022 at 10:48:06AM +0800, tangmeng wrote:
>
>
> On 2022/2/27 05:02, Luis Chamberlain wrote:
>
> >
> > Thanks but please send a v3 including all the other patches as well
> > and collecting the Reviewed/Acked-bys, etc. This can be sent *after*
> > your v3 of the optimization work.
> >
> I have noticed that there is a conflict between sysctl-next and linux-next.
> Do I resubmit the patch based on linux-next, or after you deal with the
> conflict between sysctl-next and linux-next, I resubmit based on
> sysctl-next？
You can use sysctl-next now to base your development changes. Feel free
to send more changes.
Luis