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@xxxxxxxxx>
> > > > > >
> > > > > > 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@xxxxxxxxxx
-- 

Joel Granados