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