mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@kernel.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Uros Bizjak <ubizjak@gmail.com>,
	Joel Fernandes <joel@joelfernandes.org>,
	rcu@vger.kernel.org, linux-kernel@vger.kernel.org,
	Frederic Weisbecker <frederic@kernel.org>,
	Neeraj Upadhyay <quic_neeraju@quicinc.com>,
	Josh Triplett <josh@joshtriplett.org>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Lai Jiangshan <jiangshanlai@gmail.com>
Subject: Re: [PATCH] rcu: use try_cmpxchg in check_cpu_stall
Date: Wed, 1 Mar 2023 12:36:45 -0800	[thread overview]
Message-ID: <20230301203645.GG2948950@paulmck-ThinkPad-P17-Gen-1> (raw)
In-Reply-To: <20230301151826.014c5977@gandalf.local.home>

On Wed, Mar 01, 2023 at 03:18:26PM -0500, Steven Rostedt wrote:
> On Wed, 1 Mar 2023 12:08:20 -0800
> "Paul E. McKenney" <paulmck@kernel.org> wrote:
> 
> > > Attached patch implements this suggestion.  
> > 
> > Please help me out here.
> > 
> > Why on earth are we even discussing making this change to code that
> > normally never executes?  Performance is not a consideration here.
> > 
> > What am I missing here?  Is there some sort of forward-progress
> > issue that this change addresses?
> 
> Well, we sorta hijacked this thread. It turned into a more general
> discussion, as there is code that this change will be useful for
> (ring_buffer.c), but we just happen to be having the discussion here.
> 
> Where it will at most remove some text and give you back a few extra bytes
> of memory ;-)
> 
> But if we do use cmpxchg_success() IMHO, it does improve readability.
> 
> > -	    cmpxchg(&rcu_state.jiffies_stall, js, jn) == js) {
> > +	    cmpxchg_success(&rcu_state.jiffies_stall, js, jn)) {

Some years down the road, should cmpxchg_success() be on the tip of
the tongue of every kernel hacker, perhaps.  Or perhaps not.

In the meantime, we have yet another abysmally documented atomic
operation that is not well known throughout the community.  And then the
people coming across this curse everyone who had anything to do with it,
as they search the source code, dig through assembly output, and so on
trying to work out exactly what this thing does.

Sorry, but no way.

Again, unless there is some sort of forward-progress argument or
similar convincing argument.

							Thanx, Paul

  reply	other threads:[~2023-03-01 20:36 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-28 15:51 Uros Bizjak
2023-02-28 20:39 ` Joel Fernandes
2023-02-28 20:56   ` Joel Fernandes
2023-02-28 21:03   ` Steven Rostedt
2023-02-28 21:29     ` Paul E. McKenney
2023-02-28 21:41       ` Steven Rostedt
2023-02-28 21:56         ` Paul E. McKenney
2023-02-28 23:30         ` Joel Fernandes
2023-03-01  0:08           ` Steven Rostedt
2023-03-01  0:45             ` Joel Fernandes
2023-03-01 10:28             ` Uros Bizjak
2023-03-01 16:38               ` Steven Rostedt
2023-03-01 18:43                 ` Uros Bizjak
2023-03-01 18:52                   ` Steven Rostedt
2023-03-01 19:18                     ` Uros Bizjak
2023-03-01 19:43                       ` Steven Rostedt
2023-03-01 19:46                         ` Joel Fernandes
2023-03-01 19:45                       ` Joel Fernandes
2023-03-01 20:08                   ` Paul E. McKenney
2023-03-01 20:18                     ` Joel Fernandes
2023-03-01 20:18                     ` Steven Rostedt
2023-03-01 20:36                       ` Paul E. McKenney [this message]
2023-03-01 20:46                         ` Steven Rostedt
2023-03-01 21:29                           ` Paul E. McKenney
2023-03-01  9:52   ` Uros Bizjak

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=20230301203645.GG2948950@paulmck-ThinkPad-P17-Gen-1 \
    --to=paulmck@kernel.org \
    --cc=frederic@kernel.org \
    --cc=jiangshanlai@gmail.com \
    --cc=joel@joelfernandes.org \
    --cc=josh@joshtriplett.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=quic_neeraju@quicinc.com \
    --cc=rcu@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=ubizjak@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®