[PATCH v2] drop_caches: re-enable message after disabling

[PATCH v2] drop_caches: re-enable message after disabling

[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.

Signed-off-by: Ruiwu Chen <rwchen404@gmail.com>
---
v2: - updated Documentation/ to note this new API.
    - renamed the variable.
 Documentation/admin-guide/sysctl/vm.rst | 11 ++++++++++-
 fs/drop_caches.c                        |  9 ++++++---
 kernel/sysctl.c                         |  2 +-
 3 files changed, 17 insertions(+), 5 deletions(-)

diff --git a/Documentation/admin-guide/sysctl/vm.rst b/Documentation/admin-guide/sysctl/vm.rst
index f48eaa98d22d..1b9ae9bc6cf9 100644
--- a/Documentation/admin-guide/sysctl/vm.rst
+++ b/Documentation/admin-guide/sysctl/vm.rst
@@ -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
 ===================
diff --git a/fs/drop_caches.c b/fs/drop_caches.c
index d45ef541d848..5d02c1d99d9f 100644
--- a/fs/drop_caches.c
+++ b/fs/drop_caches.c
@@ -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 silent;
 
 		if (sysctl_drop_caches & 1) {
 			lru_add_drain_all();
@@ -68,12 +68,15 @@ 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 = false;
+		else if (sysctl_drop_caches == 4)
+			silent = true;
 	}
 	return 0;
 }
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index cb57da499ebb..f2e06e074724 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -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,
 	},
 	{
-- 
2.27.0

[PATCH v2] drop_caches: re-enable message after disabling

[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.

Signed-off-by: Ruiwu Chen <rwchen404@gmail.com>
---
v2: - updated Documentation/ to note this new API.
    - renamed the variable.
 Documentation/admin-guide/sysctl/vm.rst | 11 ++++++++++-
 fs/drop_caches.c                        |  9 ++++++---
 kernel/sysctl.c                         |  2 +-
 3 files changed, 17 insertions(+), 5 deletions(-)

diff --git a/Documentation/admin-guide/sysctl/vm.rst b/Documentation/admin-guide/sysctl/vm.rst
index f48eaa98d22d..1b9ae9bc6cf9 100644
--- a/Documentation/admin-guide/sysctl/vm.rst
+++ b/Documentation/admin-guide/sysctl/vm.rst
@@ -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
 ===================
diff --git a/fs/drop_caches.c b/fs/drop_caches.c
index d45ef541d848..5d02c1d99d9f 100644
--- a/fs/drop_caches.c
+++ b/fs/drop_caches.c
@@ -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 silent;
 
 		if (sysctl_drop_caches & 1) {
 			lru_add_drain_all();
@@ -68,12 +68,15 @@ 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 = false;
+		else if (sysctl_drop_caches == 4)
+			silent = true;
 	}
 	return 0;
 }
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index cb57da499ebb..f2e06e074724 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -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,
 	},
 	{
-- 
2.27.0

[PATCH v2] drop_caches: re-enable message after disabling

[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.

Signed-off-by: Ruiwu Chen <rwchen404@gmail.com>
---
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(-)

diff --git a/Documentation/admin-guide/sysctl/vm.rst b/Documentation/admin-guide/sysctl/vm.rst
index f48eaa98d22d..ef73d36e8b84 100644
--- a/Documentation/admin-guide/sysctl/vm.rst
+++ b/Documentation/admin-guide/sysctl/vm.rst
@@ -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
 ===================
diff --git a/fs/drop_caches.c b/fs/drop_caches.c
index 019a8b4eaaf9..a49af7023886 100644
--- a/fs/drop_caches.c
+++ b/fs/drop_caches.c
@@ -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,
 	},
 };
-- 
2.27.0

Re: [PATCH v2] drop_caches: re-enable message after disabling

[Luis Chamberlain]

On Sat, Feb 22, 2025 at 04:45:13PM +0800, Ruiwu Chen wrote:
> 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.
> 
> Signed-off-by: Ruiwu Chen <rwchen404@gmail.com>

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

> ---
> 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(-)
> 
> diff --git a/Documentation/admin-guide/sysctl/vm.rst b/Documentation/admin-guide/sysctl/vm.rst
> index f48eaa98d22d..ef73d36e8b84 100644
> --- a/Documentation/admin-guide/sysctl/vm.rst
> +++ b/Documentation/admin-guide/sysctl/vm.rst
> @@ -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
>  ===================
> diff --git a/fs/drop_caches.c b/fs/drop_caches.c
> index 019a8b4eaaf9..a49af7023886 100644
> --- a/fs/drop_caches.c
> +++ b/fs/drop_caches.c
> @@ -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,
>  	},
>  };
> -- 
> 2.27.0
> 

Re: [PATCH v2] drop_caches: re-enable message after disabling

[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.
>> 
>> Signed-off-by: Ruiwu Chen <rwchen404@gmail.com>
>
> 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

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

>
>> ---
>> 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(-)
>> 
>> diff --git a/Documentation/admin-guide/sysctl/vm.rst b/Documentation/admin-guide/sysctl/vm.rst
>> index f48eaa98d22d..ef73d36e8b84 100644
>> --- a/Documentation/admin-guide/sysctl/vm.rst
>> +++ b/Documentation/admin-guide/sysctl/vm.rst
>> @@ -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
>>  ===================
>> diff --git a/fs/drop_caches.c b/fs/drop_caches.c
>> index 019a8b4eaaf9..a49af7023886 100644
>> --- a/fs/drop_caches.c
>> +++ b/fs/drop_caches.c
>> @@ -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,
>>  	},
>>  };
>> -- 
>> 2.27.0
>> 

Re: [PATCH v2] drop_caches: re-enable message after disabling

[Joel Granados]

On Sat, Mar 08, 2025 at 04:05:49PM +0800, Ruiwu Chen wrote:
> >> 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.
> >> 
> >> Signed-off-by: Ruiwu Chen <rwchen404@gmail.com>
> >
> > 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
> 
> 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.

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

Best
> 
> Ruiwu
> 
> >
> >> ---
> >> v2: - updated Documentation/ to note this new API.
> >>     - renamed the variable.
...
> >> @@ -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,
> >>  	},
> >>  };
> >> -- 
> >> 2.27.0
> >> 

-- 

Joel Granados

Re: [PATCH v2] drop_caches: re-enable message after disabling

[Luis Chamberlain]

On Sat, Mar 08, 2025 at 04:05:49PM +0800, Ruiwu Chen wrote:
> >> 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.
> >> 
> >> Signed-off-by: Ruiwu Chen <rwchen404@gmail.com>
> >
> > 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
> 
> 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.

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

Re: [PATCH v2] drop_caches: re-enable message after disabling

[Luis Chamberlain]

On Mon, Mar 10, 2025 at 02:51:11PM +0100, Joel Granados wrote:
> On Sat, Mar 08, 2025 at 04:05:49PM +0800, Ruiwu Chen wrote:
> > >> 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.
> > >> 
> > >> Signed-off-by: Ruiwu Chen <rwchen404@gmail.com>
> > >
> > > 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
> > 
> > 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.
> 
> So can you use ^= or not?

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

> 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

Re: [PATCH v2] drop_caches: re-enable message after disabling

[Joel Granados]

On Wed, Mar 12, 2025 at 03:55:22PM -0700, Luis Chamberlain wrote:
> On Mon, Mar 10, 2025 at 02:51:11PM +0100, Joel Granados wrote:
> > On Sat, Mar 08, 2025 at 04:05:49PM +0800, Ruiwu Chen wrote:
> > > >> 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.
> > > >> 
> > > >> Signed-off-by: Ruiwu Chen <rwchen404@gmail.com>
> > > >
> > > > 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
> > > 
> > > 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.
> > 
> > So can you use ^= or not?
> 
> No,  ^= does not work, see a boolean truth table.
> 
> > 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


> 
>   Luis

-- 

Joel Granados

Re: [PATCH v2] drop_caches: re-enable message after disabling

[Joel Granados]

On Wed, Mar 12, 2025 at 03:55:22PM -0700, Luis Chamberlain wrote:
> On Mon, Mar 10, 2025 at 02:51:11PM +0100, Joel Granados wrote:
> > On Sat, Mar 08, 2025 at 04:05:49PM +0800, Ruiwu Chen wrote:
> > > >> 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.
> > > >> 
> > > >> Signed-off-by: Ruiwu Chen <rwchen404@gmail.com>
> > > >
> > > > 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
> > > 
> > > 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.
> > 
> > So can you use ^= or not?
> 
> No,  ^= does not work, see a boolean truth table.
> 
> > 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

-- 

Joel Granados

Re: [PATCH v2] drop_caches: re-enable message after disabling

[Ruiwu Chen]

> On Wed, Mar 12, 2025 at 03:55:22PM -0700, Luis Chamberlain wrote:
> > On Mon, Mar 10, 2025 at 02:51:11PM +0100, Joel Granados wrote:
> > > On Sat, Mar 08, 2025 at 04:05:49PM +0800, Ruiwu Chen wrote:
> > > > >> 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.
> > > > >> 
> > > > >> Signed-off-by: Ruiwu Chen <rwchen404@gmail.com>
> > > > >
> > > > > 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
> > > >
> > > > 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.
> > >
> > > 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) -> ...
 
> >
> > > 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
...

> >
> > 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
> 
> -- 
> 
> Joel Granados

Ruiwu

Re: [PATCH v2] drop_caches: re-enable message after disabling

[Joel Granados]

On Fri, Mar 14, 2025 at 08:28:03PM +0800, Ruiwu Chen wrote:
> > On Wed, Mar 12, 2025 at 03:55:22PM -0700, Luis Chamberlain wrote:
> > > On Mon, Mar 10, 2025 at 02:51:11PM +0100, Joel Granados wrote:
> > > > On Sat, Mar 08, 2025 at 04:05:49PM +0800, Ruiwu Chen wrote:
> > > > > >> 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.
> > > > > >> 
> > > > > >> Signed-off-by: Ruiwu Chen <rwchen404@gmail.com>
> > > > > >
> > > > > > 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
> > > > >
> > > > > 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.
> > > >
> > > > 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
As I read it, its should be
echo 3: free slab and pagecache     and enable message

> 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".

> 
> 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/20250313-jag-drop_caches_msg-v1-1-c2e4e7874b72@kernel.org
-- 

Joel Granados