Re: [Xen-devel] [PATCH] documentation: Add disclaimer

On Wed, Jan 27, 2016 at 02:57:07PM +, David Howells wrote: > Peter Zijlstra wrote: > > > +== > > +DISCLAIMER > > +== > > + > > +This document is not a specification; it is intentionally (for the sake of > > +brevity) and unintentionally (due to being

Re: [Xen-devel] [PATCH] documentation: Add disclaimer

On Wed, Jan 27, 2016 at 09:35:46AM +0100, Peter Zijlstra wrote: > On Tue, Jan 26, 2016 at 12:11:43PM -0800, Paul E. McKenney wrote: > > So Peter, would you like to update your patch to include yourself > > and Will as authors? > > Sure, here goes. > > --- > Subject:

Re: [Xen-devel] [v3,11/41] mips: reuse asm-generic/barrier.h

On Wed, Jan 27, 2016 at 10:25:46AM +, Will Deacon wrote: > On Tue, Jan 26, 2016 at 11:58:20AM -0800, Paul E. McKenney wrote: > > On Tue, Jan 26, 2016 at 12:16:09PM +, Will Deacon wrote: > > > On Mon, Jan 25, 2016 at 10:03:22PM -0800, Paul E. McKenney wrote: > >

Re: [Xen-devel] [v3,11/41] mips: reuse asm-generic/barrier.h

On Tue, Jan 26, 2016 at 11:19:27AM +0100, Peter Zijlstra wrote: > On Mon, Jan 25, 2016 at 10:03:22PM -0800, Paul E. McKenney wrote: > > On Mon, Jan 25, 2016 at 04:42:43PM +, Will Deacon wrote: > > > On Fri, Jan 15, 2016 at 01:58:53PM -0800, Paul E. McKenney wrote: > >

Re: [Xen-devel] [v3,11/41] mips: reuse asm-generic/barrier.h

On Tue, Jan 26, 2016 at 11:24:02AM +0100, Peter Zijlstra wrote: > On Thu, Jan 14, 2016 at 02:20:46PM -0800, Paul E. McKenney wrote: > > On Thu, Jan 14, 2016 at 01:24:34PM -0800, Leonid Yegoshin wrote: > > > On 01/14/2016 12:48 PM, Paul E. McKenney wrote: > > > >

Re: [Xen-devel] [v3,11/41] mips: reuse asm-generic/barrier.h

On Tue, Jan 26, 2016 at 11:44:46AM -0800, Linus Torvalds wrote: > On Tue, Jan 26, 2016 at 9:22 AM, Peter Zijlstra wrote: > > > > This is distinct from: > > That may be distinct, but: > > > struct foo *x = READ_ONCE(*ptr); > > smp_read_barrier_depends(); > >

Re: [Xen-devel] [v3,11/41] mips: reuse asm-generic/barrier.h

On Tue, Jan 26, 2016 at 12:16:09PM +, Will Deacon wrote: > On Mon, Jan 25, 2016 at 10:03:22PM -0800, Paul E. McKenney wrote: > > On Mon, Jan 25, 2016 at 04:42:43PM +, Will Deacon wrote: > > > On Fri, Jan 15, 2016 at 01:58:53PM -0800, Paul E. McKenney wrote: > > >

Re: [Xen-devel] [v3,11/41] mips: reuse asm-generic/barrier.h

On Wed, Jan 27, 2016 at 12:52:07AM +0800, Boqun Feng wrote: > Hi Paul, > > On Mon, Jan 18, 2016 at 07:46:29AM -0800, Paul E. McKenney wrote: > > On Mon, Jan 18, 2016 at 04:19:29PM +0800, Herbert Xu wrote: > > > Paul E. McKenney <paul...@linux.vnet.ibm.com> wrote:

Re: [Xen-devel] [v3,11/41] mips: reuse asm-generic/barrier.h

; + > > > > LINUX KERNEL MEMORY BARRIERS > > > > @@ -5,6 +6,22 @@ > > By: David Howells <dhowe...@redhat.com> > > Paul E. McKenney <paul...@linux.vnet.ibm.com> > > &g

Re: [Xen-devel] [v3,11/41] mips: reuse asm-generic/barrier.h

On Tue, Jan 26, 2016 at 02:33:40PM -0800, Linus Torvalds wrote: > On Tue, Jan 26, 2016 at 2:15 PM, Linus Torvalds > wrote: > > > > You might as well just write it as > > > > struct foo x = READ_ONCE(*ptr); > > x->bar = 5; > > > > because that

Re: [Xen-devel] [v3,11/41] mips: reuse asm-generic/barrier.h

On Tue, Jan 26, 2016 at 12:10:10PM +, Will Deacon wrote: > On Mon, Jan 25, 2016 at 05:06:46PM -0800, Paul E. McKenney wrote: > > On Mon, Jan 25, 2016 at 02:41:34PM +, Will Deacon wrote: > > > On Fri, Jan 15, 2016 at 11:28:45AM -0800, Paul E. McKenney wrote: > >

Re: [Xen-devel] [v3,11/41] mips: reuse asm-generic/barrier.h

On Tue, Jan 26, 2016 at 03:45:23PM -0800, Linus Torvalds wrote: > On Tue, Jan 26, 2016 at 3:29 PM, Paul E. McKenney > <paul...@linux.vnet.ibm.com> wrote: > > > > No trailing data-dependent read, so agreed, no smp_read_barrier_depends() > > needed. That said, I be

Re: [Xen-devel] [v3,11/41] mips: reuse asm-generic/barrier.h

On Mon, Jan 25, 2016 at 06:02:34PM +, Will Deacon wrote: > Hi Paul, > > On Fri, Jan 15, 2016 at 09:39:12AM -0800, Paul E. McKenney wrote: > > On Fri, Jan 15, 2016 at 09:55:54AM +0100, Peter Zijlstra wrote: > > > On Thu, Jan 14, 2016 at 01:29:13PM -0800, Paul E. Mc

Re: [Xen-devel] [v3,11/41] mips: reuse asm-generic/barrier.h

On Mon, Jan 25, 2016 at 04:42:43PM +, Will Deacon wrote: > On Fri, Jan 15, 2016 at 01:58:53PM -0800, Paul E. McKenney wrote: > > On Fri, Jan 15, 2016 at 10:27:14PM +0100, Peter Zijlstra wrote: > > > On Fri, Jan 15, 2016 at 09:46:12AM -0800, Paul E. McKenney wrote: > >

Re: [Xen-devel] [v3,11/41] mips: reuse asm-generic/barrier.h

On Mon, Jan 25, 2016 at 02:41:34PM +, Will Deacon wrote: > On Fri, Jan 15, 2016 at 11:28:45AM -0800, Paul E. McKenney wrote: > > On Fri, Jan 15, 2016 at 09:54:01AM -0800, Paul E. McKenney wrote: > > > On Fri, Jan 15, 2016 at 10:24:32AM +, Will Deacon wrote: > > >

Re: [Xen-devel] [v3,11/41] mips: reuse asm-generic/barrier.h

On Mon, Jan 18, 2016 at 04:19:29PM +0800, Herbert Xu wrote: > Paul E. McKenney <paul...@linux.vnet.ibm.com> wrote: > > > > You could use SYNC_ACQUIRE() to implement read_barrier_depends() and > > smp_read_barrier_depends(), but SYNC_RMB probably does

Re: [Xen-devel] [v3,11/41] mips: reuse asm-generic/barrier.h

On Fri, Jan 15, 2016 at 09:55:54AM +0100, Peter Zijlstra wrote: > On Thu, Jan 14, 2016 at 01:29:13PM -0800, Paul E. McKenney wrote: > > So smp_mb() provides transitivity, as do pairs of smp_store_release() > > and smp_read_acquire(), > > But they provide different grades o

Re: [Xen-devel] [v3,11/41] mips: reuse asm-generic/barrier.h

On Fri, Jan 15, 2016 at 10:13:48AM +0100, Peter Zijlstra wrote: > On Fri, Jan 15, 2016 at 09:55:54AM +0100, Peter Zijlstra wrote: > > On Thu, Jan 14, 2016 at 01:29:13PM -0800, Paul E. McKenney wrote: > > > So smp_mb() provides transitivity, as do pairs of

Re: [Xen-devel] [v3,11/41] mips: reuse asm-generic/barrier.h

On Fri, Jan 15, 2016 at 10:24:32AM +, Will Deacon wrote: > On Thu, Jan 14, 2016 at 02:55:10PM -0800, Paul E. McKenney wrote: > > On Thu, Jan 14, 2016 at 01:36:50PM -0800, Leonid Yegoshin wrote: > > > On 01/14/2016 01:29 PM, Paul E. McKenney wrote: > > > > > >

Re: [Xen-devel] [v3,11/41] mips: reuse asm-generic/barrier.h

On Fri, Jan 15, 2016 at 09:54:01AM -0800, Paul E. McKenney wrote: > On Fri, Jan 15, 2016 at 10:24:32AM +, Will Deacon wrote: > > On Thu, Jan 14, 2016 at 02:55:10PM -0800, Paul E. McKenney wrote: > > > On Thu, Jan 14, 2016 at 01:36:50PM -0800, Leonid Yegoshin wrote: > >

Re: [Xen-devel] [v3,11/41] mips: reuse asm-generic/barrier.h

On Fri, Jan 15, 2016 at 10:27:14PM +0100, Peter Zijlstra wrote: > On Fri, Jan 15, 2016 at 09:46:12AM -0800, Paul E. McKenney wrote: > > On Fri, Jan 15, 2016 at 10:13:48AM +0100, Peter Zijlstra wrote: > > > > And the stuff we're confused about is how best to e

Re: [Xen-devel] [v3,11/41] mips: reuse asm-generic/barrier.h

On Fri, Jan 15, 2016 at 10:29:12PM +0100, Peter Zijlstra wrote: > On Fri, Jan 15, 2016 at 09:39:12AM -0800, Paul E. McKenney wrote: > > Should we start putting litmus tests for the various examples > > somewhere, perhaps in a litmus-tests directory within each participating >

Re: [Xen-devel] [v3,11/41] mips: reuse asm-generic/barrier.h

On Thu, Jan 14, 2016 at 12:04:45PM +, Will Deacon wrote: > On Wed, Jan 13, 2016 at 12:58:22PM -0800, Leonid Yegoshin wrote: > > On 01/13/2016 12:48 PM, Peter Zijlstra wrote: > > >On Wed, Jan 13, 2016 at 11:02:35AM -0800, Leonid Yegoshin wrote: > > > > > >>I ask HW team about it but I have a

Re: [Xen-devel] [v3,11/41] mips: reuse asm-generic/barrier.h

On Thu, Jan 14, 2016 at 01:24:34PM -0800, Leonid Yegoshin wrote: > On 01/14/2016 12:48 PM, Paul E. McKenney wrote: > > > >So SYNC_RMB is intended to implement smp_rmb(), correct? > Yes. > > > >You could use SYNC_ACQUIRE() to implement read_barrier_depends() a

Re: [Xen-devel] [v3,11/41] mips: reuse asm-generic/barrier.h

On Thu, Jan 14, 2016 at 01:45:44PM -0800, Leonid Yegoshin wrote: > On 01/14/2016 01:34 PM, Paul E. McKenney wrote: > >On Thu, Jan 14, 2016 at 12:46:43PM -0800, Leonid Yegoshin wrote: > >>On 01/14/2016 12:15 PM, Peter Zijlstra wrote: > >>>On Thu, Jan 14, 2016 at 11:

Re: [Xen-devel] [v3,11/41] mips: reuse asm-generic/barrier.h

On Thu, Jan 14, 2016 at 03:33:40PM -0800, Leonid Yegoshin wrote: > On 01/14/2016 02:55 PM, Paul E. McKenney wrote: > >OK, so it looks like Will was asking not about WRC+addr+addr, but instead > >about WRC+sync+addr. > (He actually asked twice about this and that too but skip

Re: [Xen-devel] [v3,11/41] mips: reuse asm-generic/barrier.h

On Thu, Jan 14, 2016 at 01:36:50PM -0800, Leonid Yegoshin wrote: > On 01/14/2016 01:29 PM, Paul E. McKenney wrote: > > > >>On 01/14/2016 12:34 PM, Paul E. McKenney wrote: > >>> > >>>The WRC+addr+addr is OK because data dependencies are not requ

Re: [Xen-devel] [v3,11/41] mips: reuse asm-generic/barrier.h

On Thu, Jan 14, 2016 at 12:46:43PM -0800, Leonid Yegoshin wrote: > On 01/14/2016 12:15 PM, Peter Zijlstra wrote: > >On Thu, Jan 14, 2016 at 11:42:02AM -0800, Leonid Yegoshin wrote: > >>An the only point - please use an appropriate SYNC_* barriers instead of > >>heavy bold hammer. That stuff was

Re: [Xen-devel] [v3,11/41] mips: reuse asm-generic/barrier.h

On Thu, Jan 14, 2016 at 01:01:05PM -0800, Leonid Yegoshin wrote: > I need some time to understand your test examples. However, Understood. > On 01/14/2016 12:34 PM, Paul E. McKenney wrote: > > > > > >The WRC+addr+addr is OK because data dependencies are not required to be

Re: [Xen-devel] [v3,11/41] mips: reuse asm-generic/barrier.h

On Thu, Jan 14, 2016 at 12:12:53PM -0800, Leonid Yegoshin wrote: > On 01/14/2016 04:04 AM, Will Deacon wrote: > >Consequently, it's important that the architecture back-ends > >implement these portable primitives (e.g. smp_mb()) in a way that > >satisfies the kernel memory model so that core code

Re: [Xen-devel] [v3,11/41] mips: reuse asm-generic/barrier.h

On Thu, Jan 14, 2016 at 11:28:18AM -0800, Leonid Yegoshin wrote: > On 01/14/2016 04:14 AM, Will Deacon wrote: > >On Wed, Jan 13, 2016 at 02:26:16PM -0800, Leonid Yegoshin wrote: > > > >> Moreover, there are voices against guarantee that it will be in future > >>and that voices point me to

Re: [Xen-devel] [v3,11/41] mips: reuse asm-generic/barrier.h

On Thu, Jan 14, 2016 at 09:15:13PM +0100, Peter Zijlstra wrote: > On Thu, Jan 14, 2016 at 11:42:02AM -0800, Leonid Yegoshin wrote: > > An the only point - please use an appropriate SYNC_* barriers instead of > > heavy bold hammer. That stuff was design explicitly to support the > > requirements of

Re: [Xen-devel] [PATCH v3 01/41] lcoking/barriers, arch: Use smp barriers in smp_store_release()

ad.org> > Cc: <linux-a...@vger.kernel.org> > Cc: Andrew Morton <a...@linux-foundation.org> > Cc: Benjamin Herrenschmidt <b...@kernel.crashing.org> > Cc: Heiko Carstens <heiko.carst...@de.ibm.com> > Cc: Linus Torvalds <torva...@linux-foundation.org> >

Re: [Xen-devel] [PATCH v3 05/41] powerpc: reuse asm-generic/barrier.h

ic/barrier.h instead. > > This is in preparation to refactoring this code area. > > Signed-off-by: Michael S. Tsirkin <m...@redhat.com> > Acked-by: Arnd Bergmann <a...@arndb.de> Looks sane to me. Reviewed-by: Paul E. McKenney <paul...@linux.vnet.ibm.com> &g

Re: [Xen-devel] [PATCH] smpboot: Add smpboot state variables instead of reusing CPU hotplug states

> Instead of reusing the states, let's add new definition inside > the smpboot.c file with explenation what those states > mean. Thanks Paul for providing them. > > Signed-off-by: Daniel Wagner <daniel.wag...@bmw-carit.de> Apologies for the delay, I didn't realize that you we

[Xen-devel] [tip:core/rcu] x86: Use common outgoing-CPU-notification code

Commit-ID: 2a442c9c6453d3d043dfd89f2e03a1deff8a6f06 Gitweb: http://git.kernel.org/tip/2a442c9c6453d3d043dfd89f2e03a1deff8a6f06 Author: Paul E. McKenney paul...@linux.vnet.ibm.com AuthorDate: Wed, 25 Feb 2015 11:42:15 -0800 Committer: Paul E. McKenney paul...@linux.vnet.ibm.com CommitDate

[Xen-devel] [PATCH v2 tip/core/rcu 02/22] x86: Use common outgoing-CPU-notification code

From: Paul E. McKenney paul...@linux.vnet.ibm.com This commit removes the open-coded CPU-offline notification with new common code. Among other things, this change avoids calling scheduler code using RCU from an offline CPU that RCU is ignoring. It also allows Xen to notice at online time

Re: [Xen-devel] [PATCH tip/core/rcu 02/20] x86: Use common outgoing-CPU-notification code

On Thu, Mar 05, 2015 at 04:17:59PM -0500, Boris Ostrovsky wrote: On 03/04/2015 10:25 AM, Paul E. McKenney wrote: On Wed, Mar 04, 2015 at 09:55:11AM -0500, Boris Ostrovsky wrote: The simple solution is to stop calling native_cpu_die() above but I'd like to use common code in native_cpu_die

Re: [Xen-devel] [PATCH tip/core/rcu 02/20] x86: Use common outgoing-CPU-notification code

On Wed, Mar 04, 2015 at 09:55:11AM -0500, Boris Ostrovsky wrote: On 03/04/2015 09:43 AM, Paul E. McKenney wrote: On Tue, Mar 03, 2015 at 02:31:51PM -0800, Paul E. McKenney wrote: On Tue, Mar 03, 2015 at 05:06:50PM -0500, Boris Ostrovsky wrote: On 03/03/2015 04:26 PM, Paul E. McKenney wrote

Re: [Xen-devel] [PATCH tip/core/rcu 02/20] x86: Use common outgoing-CPU-notification code

On Tue, Mar 03, 2015 at 02:31:51PM -0800, Paul E. McKenney wrote: On Tue, Mar 03, 2015 at 05:06:50PM -0500, Boris Ostrovsky wrote: On 03/03/2015 04:26 PM, Paul E. McKenney wrote: On Tue, Mar 03, 2015 at 03:13:07PM -0500, Boris Ostrovsky wrote: On 03/03/2015 02:42 PM, Paul E. McKenney wrote

Re: [Xen-devel] [PATCH tip/core/rcu 02/20] x86: Use common outgoing-CPU-notification code

On Tue, Mar 03, 2015 at 02:17:24PM -0500, Boris Ostrovsky wrote: On 03/03/2015 12:42 PM, Paul E. McKenney wrote: } @@ -511,7 +508,8 @@ static void xen_cpu_die(unsigned int cpu) schedule_timeout(HZ/10); } -cpu_die_common(cpu); +(void)cpu_wait_death(cpu, 5

Re: [Xen-devel] [PATCH tip/core/rcu 02/20] x86: Use common outgoing-CPU-notification code

On Tue, Mar 03, 2015 at 03:13:07PM -0500, Boris Ostrovsky wrote: On 03/03/2015 02:42 PM, Paul E. McKenney wrote: On Tue, Mar 03, 2015 at 02:17:24PM -0500, Boris Ostrovsky wrote: On 03/03/2015 12:42 PM, Paul E. McKenney wrote: } @@ -511,7 +508,8 @@ static void xen_cpu_die(unsigned int cpu

Re: [Xen-devel] [RFC v3 2/2] x86/xen: allow privcmd hypercalls to be preempted

On Thu, Jan 22, 2015 at 03:16:57PM -0500, Steven Rostedt wrote: [ Added Paul McKenney ] On Thu, 22 Jan 2015 19:39:13 +0100 Luis R. Rodriguez mcg...@suse.com wrote: Why not make this a tracepoint? Then you can enable it only when you want to. As tracepoints are also hooks, you could