From: Peter Zijlstra <peterz@infradead.org>
To: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: Davidlohr Bueso <dave@stgolabs.net>,
Ingo Molnar <mingo@redhat.com>,
Thomas Gleixner <tglx@linutronix.de>,
linux-kernel@vger.kernel.org, Davidlohr Bueso <dbueso@suse.de>
Subject: Re: [PATCH -tip 2/3] sched/wake_q: Relax to acquire semantics
Date: Tue, 15 Sep 2015 18:30:28 +0200 [thread overview]
Message-ID: <20150915163028.GG16853@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <20150915153448.GI4029@linux.vnet.ibm.com>
On Tue, Sep 15, 2015 at 08:34:48AM -0700, Paul E. McKenney wrote:
> On Tue, Sep 15, 2015 at 04:14:39PM +0200, Peter Zijlstra wrote:
> > On Tue, Sep 15, 2015 at 07:09:22AM -0700, Paul E. McKenney wrote:
> > > On Tue, Sep 15, 2015 at 02:48:00PM +0200, Peter Zijlstra wrote:
> > > > On Tue, Sep 15, 2015 at 05:41:42AM -0700, Paul E. McKenney wrote:
> > > > > > Never mind, the PPC people will implement this with lwsync and that is
> > > > > > very much not transitive IIRC.
> > > > >
> > > > > I am probably lost on context, but...
> > > > >
> > > > > It turns out that lwsync is transitive in special cases. One of them
> > > > > is a series of release-acquire pairs, which can extend indefinitely.
> > > > >
> > > > > Does that help in this case?
> > > >
> > > > Probably not, but good to know. I still don't think we want to rely on
> > > > ACQUIRE/RELEASE being transitive in general though.
> > >
> > > OK, I will bite... Why not?
> >
> > It would mean us reviewing all archs (again) and documenting it I
> > suppose. Which is of course entirely possible.
> >
> > That said, I don't think the case at hand requires it, so lets postpone
> > this for now ;-)
>
> True enough, but in my experience smp_store_release() and
> smp_load_acquire() are a -lot- easier to use than other barriers,
> and transitivity will help promote their use. So...
>
> All the TSO architectures (x86, s390, SPARC, HPPA, ...) support transitive
> smp_store_release()/smp_load_acquire() via their native ordering in
> combination with barrier() macros. x86 with CONFIG_X86_PPRO_FENCE=y,
> which is not TSO, uses an mfence instruction. Power supports this via
> lwsync's partial cumulativity. ARM64 supports it in SMP via the new ldar
> and stlr instructions (in non-SMP, it uses barrier(), which suffices
> in that case). IA64 supports this via total ordering of all release
> instructions in theory and by the actual full-barrier implementation
> in practice (and the fact that gcc emits st.rel and ld.acq instructions
> for volatile stores and loads). All other architectures use smp_mb(),
> which is transitive.
>
> Did I miss anything?
I think that about covers it.. the only odd duckling might be s390 which
is documented as TSO but recently grew smp_mb__{before,after}_atomic(),
which seems to confuse matters.
next prev parent reply other threads:[~2015-09-15 16:30 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-14 7:37 [PATCH -tip 1/3] locking/qrwlock: Rename ->lock to ->wait_lock Davidlohr Bueso
2015-09-14 7:37 ` [PATCH -tip 2/3] sched/wake_q: Relax to acquire semantics Davidlohr Bueso
2015-09-14 12:32 ` Peter Zijlstra
2015-09-14 21:08 ` Davidlohr Bueso
2015-09-15 9:49 ` Peter Zijlstra
2015-09-15 9:55 ` Peter Zijlstra
2015-09-15 12:41 ` Paul E. McKenney
2015-09-15 12:48 ` Peter Zijlstra
2015-09-15 14:09 ` Paul E. McKenney
2015-09-15 14:14 ` Peter Zijlstra
2015-09-15 15:34 ` Paul E. McKenney
2015-09-15 16:30 ` Peter Zijlstra [this message]
2015-09-15 17:09 ` Paul E. McKenney
2015-09-18 21:41 ` Paul E. McKenney
2015-09-21 9:22 ` Martin Schwidefsky
2015-09-22 10:27 ` Martin Schwidefsky
2015-09-22 12:23 ` Boqun Feng
2015-09-22 12:51 ` Martin Schwidefsky
2015-09-22 13:29 ` Boqun Feng
2015-09-22 14:33 ` Martin Schwidefsky
2015-09-22 15:28 ` Paul E. McKenney
2015-09-23 6:43 ` Martin Schwidefsky
2015-09-25 21:30 ` Paul E. McKenney
2015-09-15 19:49 ` Davidlohr Bueso
2015-09-16 9:01 ` Peter Zijlstra
2015-09-14 7:37 ` [PATCH -tip 3/3] locking/osq: Relax atomic semantics Davidlohr Bueso
2015-09-18 8:50 ` [tip:locking/core] " tip-bot for Davidlohr Bueso
2015-09-18 8:50 ` [tip:locking/core] locking/qrwlock: Rename ->lock to ->wait_lock tip-bot for Davidlohr Bueso
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=20150915163028.GG16853@twins.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=dave@stgolabs.net \
--cc=dbueso@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=tglx@linutronix.de \
/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.