All of lore.kernel.org
 help / color / mirror / Atom feed
From: Will Deacon <will.deacon@arm.com>
To: Boqun Feng <boqun.feng@gmail.com>
Cc: linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH v3] barriers: introduce smp_mb__release_acquire and update documentation
Date: Thu, 28 Jan 2016 10:01:05 +0000	[thread overview]
Message-ID: <20160128100105.GD30928@arm.com> (raw)
In-Reply-To: <20160128024623.GA14082@fixme-laptop.cn.ibm.com>

On Thu, Jan 28, 2016 at 10:46:23AM +0800, Boqun Feng wrote:
> On Wed, Jan 27, 2016 at 06:22:04PM +0000, Will Deacon wrote:
> > As much as we'd like to live in a world where RELEASE -> ACQUIRE is
> > always cheaply ordered and can be used to construct UNLOCK -> LOCK
> > definitions with similar guarantees, the grim reality is that this isn't
> > even possible on x86 (thanks to Paul for bringing us crashing down to
> > Earth).
> > 
> > This patch handles the issue by introducing a new barrier macro,
> > smp_mb__after_release_acquire, that can be placed after an ACQUIRE that
> > either reads from a RELEASE or is in program-order after a RELEASE. The
> > barrier upgrades the RELEASE-ACQUIRE pair to a full memory barrier,
> > implying global transitivity. At the moment, it doesn't have any users,
> > so its existence serves mainly as a documentation aid and a potential
> > stepping stone to the reintroduction of smp_mb__after_unlock_lock() used
> > by RCU.
> > 
> > Documentation/memory-barriers.txt is updated to describe more clearly
> > the ACQUIRE and RELEASE ordering in this area and to show some examples
> > of the new barrier in action.
> > 
> 
> Maybe also add an entry in "CPU MEMORY BARRIERS" section of
> memory-barriers.txt? Something like (copy and paste from you commit log
> ;-)):
> 
>  (*) smp_mb__after_release_acquire();
> 
>      Placed after an ACQUIRE that either reads from a RELEASE or is in
>      program-order after a RELEASE. The barrier upgrades the
>      RELEASE-ACQUIRE pair to a full memory barrier, implying global
>      transitivity.
> 
> This could give the readers an overview of the usage of this barrier.

Thanks, I'll add that.

> > diff --git a/arch/s390/include/asm/barrier.h b/arch/s390/include/asm/barrier.h
> > index 5c8db3ce61c8..ee31da604b11 100644
> > --- a/arch/s390/include/asm/barrier.h
> > +++ b/arch/s390/include/asm/barrier.h
> > @@ -45,6 +45,7 @@ do {									\
> >  	___p1;								\
> >  })
> >  
> > +#define __smp_mb__release_acquire()	__smp_mb()
> 
> Should be __smp_mb__after_release_acquire(), so is the title of this
> patch ;-)

Well spotted. That's a hangover from v2, which I'll fix.

Cheers,

Will

      reply	other threads:[~2016-01-28 10:01 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-27 18:22 [PATCH v3] barriers: introduce smp_mb__release_acquire and update documentation Will Deacon
2016-01-27 18:25 ` Peter Zijlstra
2016-01-27 18:39   ` Will Deacon
2016-01-27 23:00     ` Paul E. McKenney
2016-01-28 15:35       ` Will Deacon
2016-01-28  2:46 ` Boqun Feng
2016-01-28 10:01   ` Will Deacon [this message]

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=20160128100105.GD30928@arm.com \
    --to=will.deacon@arm.com \
    --cc=boqun.feng@gmail.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=peterz@infradead.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.