Skip to contentSkip to conversation

drop_caches: re-enable message after disabling

PATCH In review Ruiwu Chen 3 participants 12 messages Feb 16, 2025 – Mar 17, 2025

Subsystems (4)
lore
Share & tools
lore

Ruiwu Chen

author
#0 lore raw

PATCH 1/1 drop_caches: re-enable message after disabling

When 'echo 4 > /proc/sys/vm/drop_caches' the message is disabled, but there is no interface to enable the message, only by restarting the way, so I want to add the 'echo 0 > /proc/sys/vm/drop_caches' way to enabled the message again.

---
 fs/drop_caches.c | 7 +++++--
 kernel/sysctl.c  | 2 +-
 2 files changed, 6 insertions(+), 3 deletions(-)
fs/drop_caches.c +5 -2
index d45ef541d848..c90cfaf9756d 100644
@@ -57,7 +57,7 @@ int drop_caches_sysctl_handler(const struct ctl_table *table, int write,
 	if (ret)
 		return ret;
 	if (write) {
-		static int stfu;
+		static bool stfu;
 
 		if (sysctl_drop_caches & 1) {
 			lru_add_drain_all();
@@ -73,7 +73,10 @@ int drop_caches_sysctl_handler(const struct ctl_table *table, int write,
 				current->comm, task_pid_nr(current),
 				sysctl_drop_caches);
 		}
-		stfu |= sysctl_drop_caches & 4;
+		if (sysctl_drop_caches == 0)
+			stfu = false;
+		else if (sysctl_drop_caches == 4)
+			stfu = true;
 	}
 	return 0;
 }
kernel/sysctl.c +1 -1
index cb57da499ebb..f2e06e074724 100644
@@ -2088,7 +2088,7 @@ static const struct ctl_table vm_table[] = {
 		.maxlen		= sizeof(int),
 		.mode		= 0200,
 		.proc_handler	= drop_caches_sysctl_handler,
-		.extra1		= SYSCTL_ONE,
+		.extra1		= SYSCTL_ZERO,
 		.extra2		= SYSCTL_FOUR,
 	},
 	{
Signature · 1 line
2.27.0
maintainer
#1 lore raw
Quoted 52 lines · Ruiwu Chen

When 'echo 4 > /proc/sys/vm/drop_caches' the message is disabled, but there is no interface to enable the message, only by restarting the way, so I want to add the 'echo 0 > /proc/sys/vm/drop_caches' way to enabled the message again.

---
 fs/drop_caches.c | 7 +++++--
 kernel/sysctl.c  | 2 +-
 2 files changed, 6 insertions(+), 3 deletions(-)
fs/drop_caches.c +5 -2
index d45ef541d848..c90cfaf9756d 100644
@@ -57,7 +57,7 @@ int drop_caches_sysctl_handler(const struct ctl_table *table, int write,
 	if (ret)
 		return ret;
 	if (write) {
-		static int stfu;
+		static bool stfu;
 
 		if (sysctl_drop_caches & 1) {
 			lru_add_drain_all();
@@ -73,7 +73,10 @@ int drop_caches_sysctl_handler(const struct ctl_table *table, int write,
 				current->comm, task_pid_nr(current),
 				sysctl_drop_caches);
 		}
-		stfu |= sysctl_drop_caches & 4;
+		if (sysctl_drop_caches == 0)
+			stfu = false;
+		else if (sysctl_drop_caches == 4)
+			stfu = true;
 	}
 	return 0;
 }
kernel/sysctl.c +1 -1
index cb57da499ebb..f2e06e074724 100644
@@ -2088,7 +2088,7 @@ static const struct ctl_table vm_table[] = {
 		.maxlen		= sizeof(int),
 		.mode		= 0200,
 		.proc_handler	= drop_caches_sysctl_handler,
-		.extra1		= SYSCTL_ONE,
+		.extra1		= SYSCTL_ZERO,
 		.extra2		= SYSCTL_FOUR,
 	},
 	{
Signature · 1 line
2.27.0

All this has changed with Kaixiong's move of the vm_table.

Please rebase this on top of sysctl-next [1] and send a V2

Best

[1] https://git.kernel.org/pub/scm/linux/kernel/git/sysctl/sysctl.git/log/?h=sysctl-next

Signature · 1 line
Joel Granados
author
#2 lore raw

PATCH v2 1/1 drop_caches: re-enable message after disabling

When 'echo 4 > /proc/sys/vm/drop_caches' the message is disabled, but there is no interface to enable the message, only by restarting the way, so add the 'echo 0 > /proc/sys/vm/drop_caches' way to enabled the message again.

---
v2: - updated Documentation/ to note this new API.
- renamed the variable.
- rebase this on top of sysctl-next [1].
[1] https://git.kernel.org/pub/scm/linux/kernel/git/sysctl/sysctl.git/log/?h=sysctl-next

 Documentation/admin-guide/sysctl/vm.rst | 11 ++++++++++-
 fs/drop_caches.c                        | 11 +++++++----
 2 files changed, 17 insertions(+), 5 deletions(-)
Documentation/admin-guide/sysctl/vm.rst +10 -1
index f48eaa98d22d..ef73d36e8b84 100644
@@ -266,7 +266,16 @@ used::
 	cat (1234): drop_caches: 3
 
 These are informational only.  They do not mean that anything is wrong
-with your system.  To disable them, echo 4 (bit 2) into drop_caches.
+with your system.
+
+To disable informational::
+
+	echo 4 > /proc/sys/vm/drop_caches
+
+To enable informational::
+
+	echo 0 > /proc/sys/vm/drop_caches
+
 
 enable_soft_offline
 ===================
fs/drop_caches.c +7 -4
index 019a8b4eaaf9..a49af7023886 100644
@@ -57,7 +57,7 @@ static int drop_caches_sysctl_handler(const struct ctl_table *table, int write,
 	if (ret)
 		return ret;
 	if (write) {
-		static int stfu;
+		static bool silent;
 
 		if (sysctl_drop_caches & 1) {
 			lru_add_drain_all();
@@ -68,12 +68,15 @@ static int drop_caches_sysctl_handler(const struct ctl_table *table, int write,
 			drop_slab();
 			count_vm_event(DROP_SLAB);
 		}
-		if (!stfu) {
+		if (!silent) {
 			pr_info("%s (%d): drop_caches: %d\n",
 				current->comm, task_pid_nr(current),
 				sysctl_drop_caches);
 		}
-		stfu |= sysctl_drop_caches & 4;
+		if (sysctl_drop_caches == 0)
+			silent = true;
+		else if (sysctl_drop_caches == 4)
+			silent = false;
 	}
 	return 0;
 }
@@ -85,7 +88,7 @@ static const struct ctl_table drop_caches_table[] = {
 		.maxlen		= sizeof(int),
 		.mode		= 0200,
 		.proc_handler	= drop_caches_sysctl_handler,
-		.extra1		= SYSCTL_ONE,
+		.extra1		= SYSCTL_ZERO,
 		.extra2		= SYSCTL_FOUR,
 	},
 };
Signature · 1 line
2.27.0
#3 lore raw
Quoted 6 lines · Ruiwu Chen

When 'echo 4 > /proc/sys/vm/drop_caches' the message is disabled, but there is no interface to enable the message, only by restarting the way, so add the 'echo 0 > /proc/sys/vm/drop_caches' way to enabled the message again.

You are overcomplicating things, if you just want to re-enable messages you can just use:

- stfu |= sysctl_drop_caches & 4;
+ stfu = sysctl_drop_caches & 4;

The bool is there as 4 is intended as a bit flag, you can can figure out what values you want and just append 4 to it to get the expected result.

Luis

Quoted 75 lines

---
v2: - updated Documentation/ to note this new API.
- renamed the variable.
- rebase this on top of sysctl-next [1].
[1] https://git.kernel.org/pub/scm/linux/kernel/git/sysctl/sysctl.git/log/?h=sysctl-next

 Documentation/admin-guide/sysctl/vm.rst | 11 ++++++++++-
 fs/drop_caches.c                        | 11 +++++++----
 2 files changed, 17 insertions(+), 5 deletions(-)
Documentation/admin-guide/sysctl/vm.rst +10 -1
index f48eaa98d22d..ef73d36e8b84 100644
@@ -266,7 +266,16 @@ used::
 	cat (1234): drop_caches: 3
 
 These are informational only.  They do not mean that anything is wrong
-with your system.  To disable them, echo 4 (bit 2) into drop_caches.
+with your system.
+
+To disable informational::
+
+	echo 4 > /proc/sys/vm/drop_caches
+
+To enable informational::
+
+	echo 0 > /proc/sys/vm/drop_caches
+
 
 enable_soft_offline
 ===================
fs/drop_caches.c +7 -4
index 019a8b4eaaf9..a49af7023886 100644
@@ -57,7 +57,7 @@ static int drop_caches_sysctl_handler(const struct ctl_table *table, int write,
 	if (ret)
 		return ret;
 	if (write) {
-		static int stfu;
+		static bool silent;
 
 		if (sysctl_drop_caches & 1) {
 			lru_add_drain_all();
@@ -68,12 +68,15 @@ static int drop_caches_sysctl_handler(const struct ctl_table *table, int write,
 			drop_slab();
 			count_vm_event(DROP_SLAB);
 		}
-		if (!stfu) {
+		if (!silent) {
 			pr_info("%s (%d): drop_caches: %d\n",
 				current->comm, task_pid_nr(current),
 				sysctl_drop_caches);
 		}
-		stfu |= sysctl_drop_caches & 4;
+		if (sysctl_drop_caches == 0)
+			silent = true;
+		else if (sysctl_drop_caches == 4)
+			silent = false;
 	}
 	return 0;
 }
@@ -85,7 +88,7 @@ static const struct ctl_table drop_caches_table[] = {
 		.maxlen		= sizeof(int),
 		.mode		= 0200,
 		.proc_handler	= drop_caches_sysctl_handler,
-		.extra1		= SYSCTL_ONE,
+		.extra1		= SYSCTL_ZERO,
 		.extra2		= SYSCTL_FOUR,
 	},
 };
Signature · 1 line
2.27.0
author
#4 lore raw
Quoted 13 lines
Quoted 6 lines

When 'echo 4 > /proc/sys/vm/drop_caches' the message is disabled, but there is no interface to enable the message, only by restarting the way, so add the 'echo 0 > /proc/sys/vm/drop_caches' way to enabled the message again.

You are overcomplicating things, if you just want to re-enable messages you can just use:

(quoted diff) +1 -1
-		stfu |= sysctl_drop_caches & 4;
+		stfu = sysctl_drop_caches & 4;
Quoted 5 lines

The bool is there as 4 is intended as a bit flag, you can can figure out what values you want and just append 4 to it to get the expected result.

Luis

Is that what you mean ?

- stfu |= sysctl_drop_caches & 4;
+ stfu ^= sysctl_drop_caches & 4;

'echo 4 > /sys/kernel/vm/drop_caches' can disable or open messages,
This is what I originally thought, but there is uncertainty that when different operators execute the command, It is not possible to determine whether this time is enabled or turned on unless you operate it twice.

Ruiwu

Quoted 76 lines
Quoted 76 lines

---
v2: - updated Documentation/ to note this new API.
- renamed the variable.
- rebase this on top of sysctl-next [1].
[1] https://git.kernel.org/pub/scm/linux/kernel/git/sysctl/sysctl.git/log/?h=sysctl-next

 Documentation/admin-guide/sysctl/vm.rst | 11 ++++++++++-
 fs/drop_caches.c                        | 11 +++++++----
 2 files changed, 17 insertions(+), 5 deletions(-)
Documentation/admin-guide/sysctl/vm.rst +10 -1
index f48eaa98d22d..ef73d36e8b84 100644
@@ -266,7 +266,16 @@ used::
 	cat (1234): drop_caches: 3
 
 These are informational only.  They do not mean that anything is wrong
-with your system.  To disable them, echo 4 (bit 2) into drop_caches.
+with your system.
+
+To disable informational::
+
+	echo 4 > /proc/sys/vm/drop_caches
+
+To enable informational::
+
+	echo 0 > /proc/sys/vm/drop_caches
+
 
 enable_soft_offline
 ===================
fs/drop_caches.c +7 -4
index 019a8b4eaaf9..a49af7023886 100644
@@ -57,7 +57,7 @@ static int drop_caches_sysctl_handler(const struct ctl_table *table, int write,
 	if (ret)
 		return ret;
 	if (write) {
-		static int stfu;
+		static bool silent;
 
 		if (sysctl_drop_caches & 1) {
 			lru_add_drain_all();
@@ -68,12 +68,15 @@ static int drop_caches_sysctl_handler(const struct ctl_table *table, int write,
 			drop_slab();
 			count_vm_event(DROP_SLAB);
 		}
-		if (!stfu) {
+		if (!silent) {
 			pr_info("%s (%d): drop_caches: %d\n",
 				current->comm, task_pid_nr(current),
 				sysctl_drop_caches);
 		}
-		stfu |= sysctl_drop_caches & 4;
+		if (sysctl_drop_caches == 0)
+			silent = true;
+		else if (sysctl_drop_caches == 4)
+			silent = false;
 	}
 	return 0;
 }
@@ -85,7 +88,7 @@ static const struct ctl_table drop_caches_table[] = {
 		.maxlen		= sizeof(int),
 		.mode		= 0200,
 		.proc_handler	= drop_caches_sysctl_handler,
-		.extra1		= SYSCTL_ONE,
+		.extra1		= SYSCTL_ZERO,
 		.extra2		= SYSCTL_FOUR,
 	},
 };
Signature · 1 line
2.27.0
#5 lore raw
Quoted 24 lines · Ruiwu Chen
Quoted 13 lines
Quoted 6 lines

When 'echo 4 > /proc/sys/vm/drop_caches' the message is disabled, but there is no interface to enable the message, only by restarting the way, so add the 'echo 0 > /proc/sys/vm/drop_caches' way to enabled the message again.

You are overcomplicating things, if you just want to re-enable messages you can just use:

(quoted diff) +1 -1
-		stfu |= sysctl_drop_caches & 4;
+		stfu = sysctl_drop_caches & 4;
Quoted 5 lines

The bool is there as 4 is intended as a bit flag, you can can figure out what values you want and just append 4 to it to get the expected result.

Luis

Is that what you mean ?

(quoted diff) +1 -1
-               stfu |= sysctl_drop_caches & 4;
+               stfu ^= sysctl_drop_caches & 4;
Quoted 3 lines

'echo 4 > /sys/kernel/vm/drop_caches' can disable or open messages,
This is what I originally thought, but there is uncertainty that when different operators execute the command, It is not possible to determine whether this time is enabled or turned on unless you operate it twice.

The way these flags are designed are bits in a flag. If you want to disable the flag, it'll be disabled. If you want it added it must be added as a flag. So what I did was just remove the or logic as that just keeps it on forever. With XOR you end up where if you had it enabled and then want to enable it again, you disable it.

1 xor 1 = 0

The simple variable setting just always sets it and puts the burden on the operators to read the existing setting if they don't want to disable prior settings.

Luis

maintainer
#6 lore raw
In reply to Ruiwu Chen
Quoted 24 lines · Ruiwu Chen
Quoted 13 lines
Quoted 6 lines

When 'echo 4 > /proc/sys/vm/drop_caches' the message is disabled, but there is no interface to enable the message, only by restarting the way, so add the 'echo 0 > /proc/sys/vm/drop_caches' way to enabled the message again.

You are overcomplicating things, if you just want to re-enable messages you can just use:

(quoted diff) +1 -1
-		stfu |= sysctl_drop_caches & 4;
+		stfu = sysctl_drop_caches & 4;
Quoted 5 lines

The bool is there as 4 is intended as a bit flag, you can can figure out what values you want and just append 4 to it to get the expected result.

Luis

Is that what you mean ?

(quoted diff) +1 -1
-               stfu |= sysctl_drop_caches & 4;
+               stfu ^= sysctl_drop_caches & 4;
Quoted 3 lines

'echo 4 > /sys/kernel/vm/drop_caches' can disable or open messages,
This is what I originally thought, but there is uncertainty that when different operators execute the command, It is not possible to determine whether this time is enabled or turned on unless you operate it twice.

So can you use ^= or not? And what does operate it twice mean?

Best

Quoted 7 lines

Ruiwu

Quoted 4 lines
Quoted 4 lines

---
v2: - updated Documentation/ to note this new API.
- renamed the variable.

...

Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
fs/drop_caches.c +1 -1
@@ -85,7 +88,7 @@ static const struct ctl_table drop_caches_table[] = {
 		.maxlen		= sizeof(int),
 		.mode		= 0200,
 		.proc_handler	= drop_caches_sysctl_handler,
-		.extra1		= SYSCTL_ONE,
+		.extra1		= SYSCTL_ZERO,
 		.extra2		= SYSCTL_FOUR,
 	},
 };
Signature · 1 line
2.27.0
Signature · 1 line
Joel Granados
#7 lore raw
Quoted 22 lines · Joel Granados
Quoted 21 lines · Ruiwu Chen
Quoted 13 lines
Quoted 6 lines

When 'echo 4 > /proc/sys/vm/drop_caches' the message is disabled, but there is no interface to enable the message, only by restarting the way, so add the 'echo 0 > /proc/sys/vm/drop_caches' way to enabled the message again.

You are overcomplicating things, if you just want to re-enable messages you can just use:

(quoted diff) +1 -1
-		stfu |= sysctl_drop_caches & 4;
+		stfu = sysctl_drop_caches & 4;
Quoted 5 lines

The bool is there as 4 is intended as a bit flag, you can can figure out what values you want and just append 4 to it to get the expected result.

Luis

Is that what you mean ?

Quoted 8 lines
Quoted 6 lines
(quoted diff) +1 -1
-               stfu |= sysctl_drop_caches & 4;
+               stfu ^= sysctl_drop_caches & 4;

'echo 4 > /sys/kernel/vm/drop_caches' can disable or open messages,
This is what I originally thought, but there is uncertainty that when different operators execute the command, It is not possible to determine whether this time is enabled or turned on unless you operate it twice.

So can you use ^= or not?

No, ^= does not work, see a boolean truth table.

Quoted 1 line

And what does operate it twice mean?

I think the reporter meant an "sysadmin", say two folks admining a system. Since we this as a flag to enable disabling it easily we can just always check for the flag as I suggested:

stfu = sysctl_drop_caches & 4

Luis

maintainer
#8 lore raw
Quoted 34 lines · Luis Chamberlain
Quoted 22 lines · Joel Granados
Quoted 21 lines · Ruiwu Chen
Quoted 13 lines
Quoted 6 lines

When 'echo 4 > /proc/sys/vm/drop_caches' the message is disabled, but there is no interface to enable the message, only by restarting the way, so add the 'echo 0 > /proc/sys/vm/drop_caches' way to enabled the message again.

You are overcomplicating things, if you just want to re-enable messages you can just use:

(quoted diff) +1 -1
-		stfu |= sysctl_drop_caches & 4;
+		stfu = sysctl_drop_caches & 4;
Quoted 5 lines

The bool is there as 4 is intended as a bit flag, you can can figure out what values you want and just append 4 to it to get the expected result.

Luis

Is that what you mean ?

Quoted 8 lines
Quoted 6 lines
(quoted diff) +1 -1
-               stfu |= sysctl_drop_caches & 4;
+               stfu ^= sysctl_drop_caches & 4;

'echo 4 > /sys/kernel/vm/drop_caches' can disable or open messages,
This is what I originally thought, but there is uncertainty that when different operators execute the command, It is not possible to determine whether this time is enabled or turned on unless you operate it twice.

So can you use ^= or not?

No, ^= does not work, see a boolean truth table.

Quoted 7 lines
Quoted 1 line

And what does operate it twice mean?

I think the reporter meant an "sysadmin", say two folks admining a system. Since we this as a flag to enable disabling it easily we can just always check for the flag as I suggested:

stfu = sysctl_drop_caches & 4

Thx for the clarification.

I see what is happening:
Once you turn the message off, its off for ever because of the or. Removing the "or" allows turning the message on off based on the 4th bit.

I'll take your fix @Luis

Thx.

Best

Quoted 2 lines

Luis

Signature · 1 line
Joel Granados
maintainer
#9 lore raw
In reply to Luis Chamberlain
Quoted 34 lines · Luis Chamberlain
Quoted 22 lines · Joel Granados
Quoted 21 lines · Ruiwu Chen
Quoted 13 lines
Quoted 6 lines

When 'echo 4 > /proc/sys/vm/drop_caches' the message is disabled, but there is no interface to enable the message, only by restarting the way, so add the 'echo 0 > /proc/sys/vm/drop_caches' way to enabled the message again.

You are overcomplicating things, if you just want to re-enable messages you can just use:

(quoted diff) +1 -1
-		stfu |= sysctl_drop_caches & 4;
+		stfu = sysctl_drop_caches & 4;
Quoted 5 lines

The bool is there as 4 is intended as a bit flag, you can can figure out what values you want and just append 4 to it to get the expected result.

Luis

Is that what you mean ?

Quoted 8 lines
Quoted 6 lines
(quoted diff) +1 -1
-               stfu |= sysctl_drop_caches & 4;
+               stfu ^= sysctl_drop_caches & 4;

'echo 4 > /sys/kernel/vm/drop_caches' can disable or open messages,
This is what I originally thought, but there is uncertainty that when different operators execute the command, It is not possible to determine whether this time is enabled or turned on unless you operate it twice.

So can you use ^= or not?

No, ^= does not work, see a boolean truth table.

Quoted 7 lines
Quoted 1 line

And what does operate it twice mean?

I think the reporter meant an "sysadmin", say two folks admining a system. Since we this as a flag to enable disabling it easily we can just always check for the flag as I suggested:

stfu = sysctl_drop_caches & 4

I sent out a new version of this patch. Its a bit late to push it though the next merge window, so it is in sysctl-testing until the next cycle

Thx again

Best

Signature · 1 line
Joel Granados
author
#10 lore raw
Quoted 27 lines · Luis Chamberlain
Quoted 26 lines · Joel Granados
Quoted 25 lines · Ruiwu Chen
Quoted 24 lines
Quoted 13 lines
Quoted 6 lines

When 'echo 4 > /proc/sys/vm/drop_caches' the message is disabled, but there is no interface to enable the message, only by restarting the way, so add the 'echo 0 > /proc/sys/vm/drop_caches' way to enabled the message again.

You are overcomplicating things, if you just want to re-enable messages you can just use:

(quoted diff) +1 -1
-		stfu |= sysctl_drop_caches & 4;
+		stfu = sysctl_drop_caches & 4;
Quoted 5 lines

The bool is there as 4 is intended as a bit flag, you can can figure out what values you want and just append 4 to it to get the expected result.

Luis

Is that what you mean ?

(quoted diff) +1 -1
-               stfu |= sysctl_drop_caches & 4;
+               stfu ^= sysctl_drop_caches & 4;
Quoted 7 lines
Quoted 7 lines
Quoted 5 lines
Quoted 3 lines

'echo 4 > /sys/kernel/vm/drop_caches' can disable or open messages,
This is what I originally thought, but there is uncertainty that when different operators execute the command, It is not possible to determine whether this time is enabled or turned on unless you operate it twice.

So can you use ^= or not?

No, ^= does not work, see a boolean truth table.

I don't quite agree with you, you change this, echo {1,2,3} will have the meaning of enable message

The initial logic:
echo 1: free pagecache
echo 2: free slab
echo 3: free pagecache and slab
echo 4: disable message

If you change it to something like this:
stfu = sysctl_drop_caches & 4;
echo 1: free pagecache and enable message
echo 2: free slab and enable message
echo 3: free pagecache and enable message
echo 4: disable message

echo 4 becomes meaningless, when echo 4 only the next message can be disabled Unable to continuously disable echo{1,2,3}

echo {1,2,3} always enabled the message
echo {1,2,3} should not have the meaning of enabling messages

My thoughts:
stfu ^= !!(sysctl_drop_caches & 4);
echo 1: free pagecache
echo 2: free slab
echo 3: free pagecache
echo 4: disable message(odd-numbered operation), enable message(even-numbered operation)

{1, 2, 3} & 4 = 0
stfu ^ 0 = stfu
when echo{1, 2, 3} the stfu is not affected

0 ^ 1 = 1 echo 4: disable message(odd-numbered operation) 1 ^ 1 = 0 echo 4: enable message(even-numbered operation) stfu ^ 1 = !stfu

when echo 4
stfu(0) -> stfu(1) -> stfu(0) -> stfu(1) -> stfu(0) -> ...

Quoted 2 lines
Quoted 2 lines
Quoted 2 lines

And what does operate it twice mean?

echo 4 can:
stfu = 1 # turn off
stfu = 0 # turn on
stfu = 1 # turn off
stfu = 0 # turn on
...

Quoted 5 lines
Quoted 5 lines

I think the reporter meant an "sysadmin", say two folks admining a system. Since we this as a flag to enable disabling it easily we can just always check for the flag as I suggested:

Quoted 11 lines
Quoted 1 line

stfu = sysctl_drop_caches & 4

I sent out a new version of this patch. Its a bit late to push it though the next merge window, so it is in sysctl-testing until the next cycle

Thx again

Best

Signature · 1 line
Joel Granados

Ruiwu

maintainer
#11 lore raw
Quoted 44 lines · Ruiwu Chen
Quoted 27 lines · Luis Chamberlain
Quoted 26 lines · Joel Granados
Quoted 25 lines · Ruiwu Chen
Quoted 24 lines
Quoted 13 lines
Quoted 6 lines

When 'echo 4 > /proc/sys/vm/drop_caches' the message is disabled, but there is no interface to enable the message, only by restarting the way, so add the 'echo 0 > /proc/sys/vm/drop_caches' way to enabled the message again.

You are overcomplicating things, if you just want to re-enable messages you can just use:

(quoted diff) +1 -1
-		stfu |= sysctl_drop_caches & 4;
+		stfu = sysctl_drop_caches & 4;
Quoted 5 lines

The bool is there as 4 is intended as a bit flag, you can can figure out what values you want and just append 4 to it to get the expected result.

Luis

Is that what you mean ?

(quoted diff) +1 -1
-               stfu |= sysctl_drop_caches & 4;
+               stfu ^= sysctl_drop_caches & 4;
Quoted 7 lines
Quoted 7 lines
Quoted 5 lines
Quoted 3 lines

'echo 4 > /sys/kernel/vm/drop_caches' can disable or open messages,
This is what I originally thought, but there is uncertainty that when different operators execute the command, It is not possible to determine whether this time is enabled or turned on unless you operate it twice.

So can you use ^= or not?

No, ^= does not work, see a boolean truth table.

I don't quite agree with you, you change this, echo {1,2,3} will have the meaning of enable message

The initial logic:
echo 1: free pagecache
echo 2: free slab
echo 3: free pagecache and slab
echo 4: disable message

Quoted 5 lines

If you change it to something like this:
stfu = sysctl_drop_caches & 4;
echo 1: free pagecache and enable message
echo 2: free slab and enable message
echo 3: free pagecache and enable message

As I read it, its should be
echo 3: free slab and pagecache and enable message

Quoted 1 line

echo 4: disable message

This is a very good point. But the new logic does not shock me. I would actually add some rows to your explanation in the following fashion:

echo 5: free pagecache and disable message
echo 6: free slab and disable message
echo 7: free pagecache and slab and disable message
echo 0: Nothing and enable message

This is in line with the file describing a binary value where every bit position means something different. At the end its up to the maintainer to decide what is "right".

Quoted 9 lines

echo 4 becomes meaningless, when echo 4 only the next message can be disabled Unable to continuously disable echo{1,2,3}

echo {1,2,3} always enabled the message
echo {1,2,3} should not have the meaning of enabling messages

My thoughts:
stfu ^= !!(sysctl_drop_caches & 4);

This is a bit convoluted. This is more understandable IMO:

  diff --git a/fs/drop_caches.c b/fs/drop_caches.c
  index d45ef541d848..15730593ae39 100644
  --- a/fs/drop_caches.c
  +++ b/fs/drop_caches.c
  @@ -68,12 +68,13 @@ int drop_caches_sysctl_handler(const struct ctl_table *table, int write,
                          drop_slab();
                          count_vm_event(DROP_SLAB);
                  }
  +               if (sysctl_drop_caches & 4)
  +                       stfu ^= 1;
                  if (!stfu) {
                          pr_info("%s (%d): drop_caches: %d\n",
                                  current->comm, task_pid_nr(current),
                                  sysctl_drop_caches);
                  }
  -               stfu |= sysctl_drop_caches & 4;
          }
          return 0;
   }

I'll add this to the patch that I sent in [1]. If you have any more comments, please answer them in [1]

Best

[1] : https://lore.kernel.org/[email protected]

Signature · 1 line
Joel Granados