[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180711154830.GA14348@andrea>
Date: Wed, 11 Jul 2018 17:53:55 +0200
From: Andrea Parri <andrea.parri@...rulasolutions.com>
To: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Cc: linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org,
linux-doc@...r.kernel.org, Alan Stern <stern@...land.harvard.edu>,
Will Deacon <will.deacon@....com>,
Peter Zijlstra <peterz@...radead.org>,
Boqun Feng <boqun.feng@...il.com>,
Nicholas Piggin <npiggin@...il.com>,
David Howells <dhowells@...hat.com>,
Jade Alglave <j.alglave@....ac.uk>,
Luc Maranget <luc.maranget@...ia.fr>,
Akira Yokosawa <akiyks@...il.com>,
Daniel Lustig <dlustig@...dia.com>,
Jonathan Corbet <corbet@....net>
Subject: Re: [PATCH] doc: Replace smp_cond_acquire() with
smp_cond_load_acquire()
On Wed, Jul 11, 2018 at 08:38:40AM -0700, Paul E. McKenney wrote:
> On Wed, Jul 11, 2018 at 03:08:50PM +0200, Andrea Parri wrote:
> > Amend commit 1f03e8d2919270 ("locking/barriers: Replace smp_cond_acquire()
> > with smp_cond_load_acquire()") by updating the documentation accordingly.
> > Also remove some obsolete information related to the implementation.
> >
> > Signed-off-by: Andrea Parri <andrea.parri@...rulasolutions.com>
> > Cc: Alan Stern <stern@...land.harvard.edu>
> > Cc: Will Deacon <will.deacon@....com>
> > Cc: Peter Zijlstra <peterz@...radead.org>
> > Cc: Boqun Feng <boqun.feng@...il.com>
> > Cc: Nicholas Piggin <npiggin@...il.com>
> > Cc: David Howells <dhowells@...hat.com>
> > Cc: Jade Alglave <j.alglave@....ac.uk>
> > Cc: Luc Maranget <luc.maranget@...ia.fr>
> > Cc: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
> > Cc: Akira Yokosawa <akiyks@...il.com>
> > Cc: Daniel Lustig <dlustig@...dia.com>
> > Cc: Jonathan Corbet <corbet@....net>
> > ---
> > Documentation/memory-barriers.txt | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
>
> I have queued this for further review, thank you! Just to confirm,
> the reason that the old passage was obsolete is because ARMv8 implements
> smp_cond_load_acquire() as a straight acquire load, correct?
Thanks. Yes; the generic code builds on a control dependency and an
smp_acquire__after_ctrl_dep() (which defaults to smp_rmb()); but the
required ordering on arm64 is given by (its) smp_load_acquire().
I thought that entering this level of details (and keeping it up-to-
date ;) wasn't really worth/needed for this high-level doc.
Andrea
>
> Thanx, Paul
>
> > diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
> > index 0d8d7ef131e9a..c1d913944ad8b 100644
> > --- a/Documentation/memory-barriers.txt
> > +++ b/Documentation/memory-barriers.txt
> > @@ -471,8 +471,7 @@ And a couple of implicit varieties:
> > operations after the ACQUIRE operation will appear to happen after the
> > ACQUIRE operation with respect to the other components of the system.
> > ACQUIRE operations include LOCK operations and both smp_load_acquire()
> > - and smp_cond_acquire() operations. The later builds the necessary ACQUIRE
> > - semantics from relying on a control dependency and smp_rmb().
> > + and smp_cond_load_acquire() operations.
> >
> > Memory operations that occur before an ACQUIRE operation may appear to
> > happen after it completes.
> > --
> > 2.7.4
> >
>
Powered by blists - more mailing lists