All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Laight <david.laight.linux@gmail.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Nam Cao <namcao@linutronix.de>,
	Gabriele Monaco <gmonaco@redhat.com>,
	John Ogness <john.ogness@linutronix.de>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	linux-trace-kernel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] tracing: Remove pointless memory barriers
Date: Fri, 11 Jul 2025 09:29:46 +0100	[thread overview]
Message-ID: <20250711092946.1bbd58ef@pumpkin> (raw)
In-Reply-To: <20250709110827.0dce4012@batman.local.home>

On Wed, 9 Jul 2025 11:08:27 -0400
Steven Rostedt <rostedt@goodmis.org> wrote:

> On Tue, 8 Jul 2025 09:42:19 +0200
> Nam Cao <namcao@linutronix.de> wrote:
> 
> > So yes, smp_rmb() is only useful inbetween reads, and smp_wmb() is
> > only userful inbetween writes.  
> 
> Hmm, I wonder if barriers isn't needed but atomic values are?
> 
> That is, it looks like rv_monitoring_on() is looking to read the
> current state, where as turn_monitoring_on/off() changes the state.
> 
> Perhaps instead of barriers, it should use atomics?
> 
>  bool rv_monitoring_on(void)
>  {
> 	return atomic_read(&monitoring_on);
>  }
>  
>  static void turn_monitoring_off(void)
>  {
> 	atomic_set(&monitoring_on, 0);
>  }
>  
> 
> Doesn't atomic make sure the values are seen when they are changed?

No.
It normally just ensures the read/write aren't 'torn'.
Atomics are used for read-modify-writes to ensure two cpu don't
do read-read-modify-modify-write-write losing one of the changes.
(They can need special instructions for read and write - but normally don't.)
So here just the same as the volatile accesses READ_ONCE() and WRITE_ONCE().

	David


> 
> As this code is more about looking at state and not ordering, and I
> think that's what atomics are about.
> 
> -- Steve
> 


  reply	other threads:[~2025-07-11  8:29 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-26 15:19 [PATCH] tracing: Remove pointless memory barriers Nam Cao
2025-06-26 15:35 ` Steven Rostedt
2025-06-26 15:37   ` Steven Rostedt
2025-06-26 16:04   ` Nam Cao
2025-06-26 16:34     ` Steven Rostedt
2025-06-26 17:41       ` John Ogness
2025-07-03  8:05         ` Gabriele Monaco
2025-07-08  7:42           ` Nam Cao
2025-07-09 15:08             ` Steven Rostedt
2025-07-11  8:29               ` David Laight [this message]
2025-07-11 16:07                 ` Steven Rostedt
2025-07-09  8:22       ` David Laight
2025-07-22  0:49     ` Steven Rostedt

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=20250711092946.1bbd58ef@pumpkin \
    --to=david.laight.linux@gmail.com \
    --cc=gmonaco@redhat.com \
    --cc=john.ogness@linutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mhiramat@kernel.org \
    --cc=namcao@linutronix.de \
    --cc=rostedt@goodmis.org \
    /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.