linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Paul Mackerras <paulus@ozlabs.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	Boqun Feng <boqun.feng@gmail.com>,
	linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	Ingo Molnar <mingo@kernel.org>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Thomas Gleixner <tglx@linutronix.de>,
	Will Deacon <will.deacon@arm.com>,
	Waiman Long <waiman.long@hp.com>,
	Davidlohr Bueso <dave@stgolabs.net>,
	stable@vger.kernel.org
Subject: Re: [PATCH tip/locking/core v4 1/6] powerpc: atomic: Make *xchg and *cmpxchg a full barrier
Date: Mon, 26 Oct 2015 14:20:21 +1100	[thread overview]
Message-ID: <20151026032021.GA5420@iris.ozlabs.ibm.com> (raw)
In-Reply-To: <20151021081833.GB2881@worktop.programming.kicks-ass.net>

On Wed, Oct 21, 2015 at 10:18:33AM +0200, Peter Zijlstra wrote:
> On Tue, Oct 20, 2015 at 02:28:35PM -0700, Paul E. McKenney wrote:
> > I am not seeing a sync there, but I really have to defer to the
> > maintainers on this one.  I could easily have missed one.
> 
> So x86 implies a full barrier for everything that changes the CPL; and
> some form of implied ordering seems a must if you change the privilege
> level unless you tag every single load/store with the priv level at that
> time, which seems the more expensive option.
> 
> So I suspect the typical implementation will flush all load/stores,
> change the effective priv level and continue.
> 
> This can of course be implemented at a pure per CPU ordering (RCpc),
> which would be in line with the rest of Power, in which case you do
> indeed need an explicit sync to make it visible to other CPUs.

Right - interrupts and returns from interrupt are context
synchronizing operations, which means they wait until all outstanding
instructions have got to the point where they have reported any
exceptions they're going to report, which means in turn that loads and
stores have completed address translation.  But all of that doesn't
imply anything about the visibility of the loads and stores.

There is a full barrier in the context switch path, but not in the
system call entry/exit path.

Paul.

  parent reply	other threads:[~2015-10-26  3:20 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-14 15:55 [PATCH tip/locking/core v4 0/6] atomics: powerpc: Implement relaxed/acquire/release variants of some atomics Boqun Feng
2015-10-14 15:55 ` [PATCH tip/locking/core v4 1/6] powerpc: atomic: Make *xchg and *cmpxchg a full barrier Boqun Feng
2015-10-14 20:19   ` Paul E. McKenney
2015-10-14 21:04     ` Peter Zijlstra
2015-10-14 21:44       ` Paul E. McKenney
2015-10-15  0:53         ` Boqun Feng
2015-10-15  1:22           ` Boqun Feng
2015-10-15  3:07             ` Paul E. McKenney
2015-10-15  3:07           ` Paul E. McKenney
2015-10-15  4:48             ` Boqun Feng
2015-10-15 16:30               ` Paul E. McKenney
2015-10-19  0:19                 ` Boqun Feng
2015-10-15  3:11           ` Boqun Feng
2015-10-15  3:33             ` Paul E. McKenney
2015-10-15 10:35         ` Will Deacon
2015-10-15 14:40           ` Boqun Feng
2015-10-15 14:50           ` Will Deacon
2015-10-15 16:29             ` Paul E. McKenney
2015-10-15 15:42           ` Paul E. McKenney
2015-10-15 14:49     ` Boqun Feng
2015-10-15 16:16       ` Paul E. McKenney
2015-10-20  7:15     ` Boqun Feng
2015-10-20  9:21       ` Peter Zijlstra
2015-10-20 21:28         ` Paul E. McKenney
2015-10-21  8:18           ` Peter Zijlstra
2015-10-21 19:36             ` Paul E. McKenney
2015-10-26  2:06               ` Boqun Feng
2015-10-26  2:20               ` Michael Ellerman
2015-10-26  8:55                 ` Boqun Feng
2015-10-26  3:20             ` Paul Mackerras [this message]
2015-10-26  8:58               ` Boqun Feng
2015-10-21  8:45           ` Boqun Feng
2015-10-21 19:35             ` Paul E. McKenney
2015-10-21 19:48               ` Peter Zijlstra
2015-10-22 12:07                 ` Boqun Feng
2015-10-24 10:26                   ` Peter Zijlstra
2015-10-24 11:53                     ` Boqun Feng
2015-10-25 13:14                       ` Boqun Feng
2015-10-14 15:55 ` [PATCH tip/locking/core v4 2/6] atomics: Add test for atomic operations with _relaxed variants Boqun Feng
2015-10-14 15:55 ` [PATCH tip/locking/core v4 3/6] atomics: Allow architectures to define their own __atomic_op_* helpers Boqun Feng
2015-10-14 15:55 ` [PATCH tip/locking/core v4 4/6] powerpc: atomic: Implement atomic{, 64}_*_return_* variants Boqun Feng
2015-10-14 15:56 ` [PATCH tip/locking/core v4 5/6] powerpc: atomic: Implement xchg_* and atomic{, 64}_xchg_* variants Boqun Feng
2015-10-14 15:56 ` [PATCH tip/locking/core v4 6/6] powerpc: atomic: Implement cmpxchg{, 64}_* and atomic{, 64}_cmpxchg_* variants Boqun Feng

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=20151026032021.GA5420@iris.ozlabs.ibm.com \
    --to=paulus@ozlabs.org \
    --cc=benh@kernel.crashing.org \
    --cc=boqun.feng@gmail.com \
    --cc=dave@stgolabs.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mingo@kernel.org \
    --cc=mpe@ellerman.id.au \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=peterz@infradead.org \
    --cc=stable@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=waiman.long@hp.com \
    --cc=will.deacon@arm.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).