Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Thu, 3 Oct 2019 06:33:15 -0700
From:   "Paul E. McKenney" <paulmck@kernel.org>
To:     Steven Rostedt <rostedt@goodmis.org>
Cc:     David Howells <dhowells@redhat.com>, rcu@vger.kernel.org,
        linux-kernel@vger.kernel.org, mingo@kernel.org,
        jiangshanlai@gmail.com, dipankar@in.ibm.com,
        akpm@linux-foundation.org, mathieu.desnoyers@efficios.com,
        josh@joshtriplett.org, tglx@linutronix.de, peterz@infradead.org,
        edumazet@google.com, fweisbec@gmail.com, oleg@redhat.com,
        joel@joelfernandes.org, Bart Van Assche <bart.vanassche@wdc.com>,
        Christoph Hellwig <hch@lst.de>, Hannes Reinecke <hare@suse.de>,
        Johannes Thumshirn <jthumshirn@suse.de>,
        Shane M Seymour <shane.seymour@hpe.com>,
        "Martin K . Petersen" <martin.petersen@oracle.com>
Subject: Re: [PATCH tip/core/rcu 1/9] rcu: Upgrade rcu_swap_protected() to
 rcu_replace()
Message-ID: <20191003133315.GN2689@paulmck-ThinkPad-P72>
Reply-To: paulmck@kernel.org
References: <20191003014310.13262-1-paulmck@kernel.org>
 <20191003014153.GA13156@paulmck-ThinkPad-P72>
 <25408.1570091957@warthog.procyon.org.uk>
 <20191003090850.1e2561b3@gandalf.local.home>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20191003090850.1e2561b3@gandalf.local.home>
User-Agent: Mutt/1.9.4 (2018-02-28)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Thu, Oct 03, 2019 at 09:08:50AM -0400, Steven Rostedt wrote:
> On Thu, 03 Oct 2019 09:39:17 +0100
> David Howells <dhowells@redhat.com> wrote:
> 
> > paulmck@kernel.org wrote:
> > 
> > > +#define rcu_replace(rcu_ptr, ptr, c)					\
> > > +({									\
> > > +	typeof(ptr) __tmp = rcu_dereference_protected((rcu_ptr), (c));	\
> > > +	rcu_assign_pointer((rcu_ptr), (ptr));				\
> > > +	__tmp;								\
> > > +})  
> > 
> > Does it make sense to actually use xchg() if that's supported by the arch?

Historically, xchg() has been quite a bit slower than a pair of assignment
statements, in part due to the strong memory ordering guaranteed by
xchg().  Has that changed?  If so, then, agreed, it might make sense to
use xchg().

> Hmm, is there really any arch that doesn't support xchg()? It would be
> very hard to do any kind of atomic operations without it.
> 
> cmpxchg() is the one that I understand is optional by the arch.

To your point, even the old Sequent Symmetry platforms supported xchg()
back in the late 1980s and early 1990s, but only the later versions
(with 80486 and later) supported cmpxchg().

							Thanx, Paul