From: Ruiwu Chen <rwchen404@gmail.com>
To: joel.granados@kernel.org, mcgrof@kernel.org
Cc: corbet@lwn.net, keescook@chromium.org, linux-doc@vger.kernel.org,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
rwchen404@gmail.com, viro@zeniv.linux.org.uk,
zachwade.k@gmail.com
Subject: Re: [PATCH v2] drop_caches: re-enable message after disabling
Date: Fri, 14 Mar 2025 20:28:03 +0800 [thread overview]
Message-ID: <20250314122803.14568-1-rwchen404@gmail.com> (raw)
In-Reply-To: <db2zm4c5p5octh6garrnvlg3qzhvaqxtoz33f5ksegwupcbegk@jidbmdepvn57>
> 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
next prev parent reply other threads:[~2025-03-14 12:28 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-16 10:05 [PATCH] drop_caches: re-enable message after disabling Ruiwu Chen
2025-02-21 8:50 ` Joel Granados
2025-02-22 8:45 ` [PATCH v2] " Ruiwu Chen
2025-02-23 17:22 ` Luis Chamberlain
2025-03-08 8:05 ` Ruiwu Chen
2025-03-10 13:51 ` Joel Granados
2025-03-12 22:55 ` Luis Chamberlain
2025-03-13 15:19 ` Joel Granados
2025-03-13 15:52 ` Joel Granados
2025-03-14 12:28 ` Ruiwu Chen [this message]
2025-03-17 19:28 ` Joel Granados
2025-03-11 3:53 ` Luis Chamberlain
-- strict thread matches above, loose matches on Subject: below --
2025-02-16 10:17 [PATCH] " Ruiwu Chen
2025-02-20 13:18 ` [PATCH v2] " Ruiwu Chen
2025-02-17 17:33 Ruiwu Chen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250314122803.14568-1-rwchen404@gmail.com \
--to=rwchen404@gmail.com \
--cc=corbet@lwn.net \
--cc=joel.granados@kernel.org \
--cc=keescook@chromium.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mcgrof@kernel.org \
--cc=viro@zeniv.linux.org.uk \
--cc=zachwade.k@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.