Re: [PATCH tip/core/rcu 1/9] rcu: Provide GP ordering in face of migrations and delays

2017-10-09 Thread Paul E. McKenney
On Mon, Oct 09, 2017 at 10:16:37AM +0200, Peter Zijlstra wrote: > On Sat, Oct 07, 2017 at 11:28:57AM -0700, Paul E. McKenney wrote: > > But if you are saying that it would be good to have wait_for_completion() > > and complete() directly modeled at some point, no argument. In addition, > > I hope

Re: [PATCH tip/core/rcu 1/9] rcu: Provide GP ordering in face of migrations and delays

2017-10-09 Thread Paul E. McKenney
On Mon, Oct 09, 2017 at 10:16:37AM +0200, Peter Zijlstra wrote: > On Sat, Oct 07, 2017 at 11:28:57AM -0700, Paul E. McKenney wrote: > > But if you are saying that it would be good to have wait_for_completion() > > and complete() directly modeled at some point, no argument. In addition, > > I hope

Re: [PATCH tip/core/rcu 1/9] rcu: Provide GP ordering in face of migrations and delays

2017-10-09 Thread Andrea Parri
On Mon, Oct 09, 2017 at 10:16:37AM +0200, Peter Zijlstra wrote: > On Sat, Oct 07, 2017 at 11:28:57AM -0700, Paul E. McKenney wrote: > > But if you are saying that it would be good to have wait_for_completion() > > and complete() directly modeled at some point, no argument. In addition, > > I hope

Re: [PATCH tip/core/rcu 1/9] rcu: Provide GP ordering in face of migrations and delays

2017-10-09 Thread Andrea Parri
On Mon, Oct 09, 2017 at 10:16:37AM +0200, Peter Zijlstra wrote: > On Sat, Oct 07, 2017 at 11:28:57AM -0700, Paul E. McKenney wrote: > > But if you are saying that it would be good to have wait_for_completion() > > and complete() directly modeled at some point, no argument. In addition, > > I hope

Re: [PATCH tip/core/rcu 1/9] rcu: Provide GP ordering in face of migrations and delays

2017-10-09 Thread Peter Zijlstra
On Sat, Oct 07, 2017 at 11:28:57AM -0700, Paul E. McKenney wrote: > But if you are saying that it would be good to have wait_for_completion() > and complete() directly modeled at some point, no argument. In addition, > I hope that the memory model is applied to other tools that analyze kernel >

Re: [PATCH tip/core/rcu 1/9] rcu: Provide GP ordering in face of migrations and delays

2017-10-09 Thread Peter Zijlstra
On Sat, Oct 07, 2017 at 11:28:57AM -0700, Paul E. McKenney wrote: > But if you are saying that it would be good to have wait_for_completion() > and complete() directly modeled at some point, no argument. In addition, > I hope that the memory model is applied to other tools that analyze kernel >

Re: [PATCH tip/core/rcu 1/9] rcu: Provide GP ordering in face of migrations and delays

2017-10-07 Thread Paul E. McKenney
On Sat, Oct 07, 2017 at 11:29:19AM +0200, Peter Zijlstra wrote: > On Fri, Oct 06, 2017 at 08:31:05PM -0700, Paul E. McKenney wrote: > > > > > OK, I will bite... What do the smp_store_release() and the > > > > smp_load_acquire() correspond to? I see just plain locking in > > > >

Re: [PATCH tip/core/rcu 1/9] rcu: Provide GP ordering in face of migrations and delays

2017-10-07 Thread Paul E. McKenney
On Sat, Oct 07, 2017 at 11:29:19AM +0200, Peter Zijlstra wrote: > On Fri, Oct 06, 2017 at 08:31:05PM -0700, Paul E. McKenney wrote: > > > > > OK, I will bite... What do the smp_store_release() and the > > > > smp_load_acquire() correspond to? I see just plain locking in > > > >

Re: [PATCH tip/core/rcu 1/9] rcu: Provide GP ordering in face of migrations and delays

2017-10-07 Thread Peter Zijlstra
On Fri, Oct 06, 2017 at 08:31:05PM -0700, Paul E. McKenney wrote: > > > OK, I will bite... What do the smp_store_release() and the > > > smp_load_acquire() correspond to? I see just plain locking in > > > wait_for_completion() and complete(). > > > > They reflect the concept of complete() /

Re: [PATCH tip/core/rcu 1/9] rcu: Provide GP ordering in face of migrations and delays

2017-10-07 Thread Peter Zijlstra
On Fri, Oct 06, 2017 at 08:31:05PM -0700, Paul E. McKenney wrote: > > > OK, I will bite... What do the smp_store_release() and the > > > smp_load_acquire() correspond to? I see just plain locking in > > > wait_for_completion() and complete(). > > > > They reflect the concept of complete() /

Re: [PATCH tip/core/rcu 1/9] rcu: Provide GP ordering in face of migrations and delays

2017-10-06 Thread Paul E. McKenney
On Fri, Oct 06, 2017 at 10:15:37PM +0200, Peter Zijlstra wrote: > On Fri, Oct 06, 2017 at 12:18:22PM -0700, Paul E. McKenney wrote: > > > /me goes and install this herd thing again.. I'm sure I had it running > > > _somewhere_.. A well. > > > > > > C C-PaulEMcKenney-W+RWC4+2017-10-05 > > > > >

Re: [PATCH tip/core/rcu 1/9] rcu: Provide GP ordering in face of migrations and delays

2017-10-06 Thread Paul E. McKenney
On Fri, Oct 06, 2017 at 10:15:37PM +0200, Peter Zijlstra wrote: > On Fri, Oct 06, 2017 at 12:18:22PM -0700, Paul E. McKenney wrote: > > > /me goes and install this herd thing again.. I'm sure I had it running > > > _somewhere_.. A well. > > > > > > C C-PaulEMcKenney-W+RWC4+2017-10-05 > > > > >

Re: [PATCH tip/core/rcu 1/9] rcu: Provide GP ordering in face of migrations and delays

2017-10-06 Thread Peter Zijlstra
On Fri, Oct 06, 2017 at 12:18:22PM -0700, Paul E. McKenney wrote: > > /me goes and install this herd thing again.. I'm sure I had it running > > _somewhere_.. A well. > > > > C C-PaulEMcKenney-W+RWC4+2017-10-05 > > > > { > > } > > > > P0(int *a, int *x) > > { > >

Re: [PATCH tip/core/rcu 1/9] rcu: Provide GP ordering in face of migrations and delays

2017-10-06 Thread Peter Zijlstra
On Fri, Oct 06, 2017 at 12:18:22PM -0700, Paul E. McKenney wrote: > > /me goes and install this herd thing again.. I'm sure I had it running > > _somewhere_.. A well. > > > > C C-PaulEMcKenney-W+RWC4+2017-10-05 > > > > { > > } > > > > P0(int *a, int *x) > > { > >

Re: [PATCH tip/core/rcu 1/9] rcu: Provide GP ordering in face of migrations and delays

2017-10-06 Thread Paul E. McKenney
On Fri, Oct 06, 2017 at 11:07:23AM +0200, Peter Zijlstra wrote: > On Thu, Oct 05, 2017 at 11:22:04AM -0700, Paul E. McKenney wrote: > > Hmmm... Here is what I was worried about: > > > > C C-PaulEMcKenney-W+RWC4+2017-10-05 > > > > { > > } > > > > P0(int *a, int *x) > > { > >

Re: [PATCH tip/core/rcu 1/9] rcu: Provide GP ordering in face of migrations and delays

2017-10-06 Thread Paul E. McKenney
On Fri, Oct 06, 2017 at 11:07:23AM +0200, Peter Zijlstra wrote: > On Thu, Oct 05, 2017 at 11:22:04AM -0700, Paul E. McKenney wrote: > > Hmmm... Here is what I was worried about: > > > > C C-PaulEMcKenney-W+RWC4+2017-10-05 > > > > { > > } > > > > P0(int *a, int *x) > > { > >

Re: [PATCH tip/core/rcu 1/9] rcu: Provide GP ordering in face of migrations and delays

2017-10-06 Thread Peter Zijlstra
On Thu, Oct 05, 2017 at 11:22:04AM -0700, Paul E. McKenney wrote: > Hmmm... Here is what I was worried about: > > C C-PaulEMcKenney-W+RWC4+2017-10-05 > > { > } > > P0(int *a, int *x) > { > WRITE_ONCE(*a, 1); > smp_mb(); /* Lock

Re: [PATCH tip/core/rcu 1/9] rcu: Provide GP ordering in face of migrations and delays

2017-10-06 Thread Peter Zijlstra
On Thu, Oct 05, 2017 at 11:22:04AM -0700, Paul E. McKenney wrote: > Hmmm... Here is what I was worried about: > > C C-PaulEMcKenney-W+RWC4+2017-10-05 > > { > } > > P0(int *a, int *x) > { > WRITE_ONCE(*a, 1); > smp_mb(); /* Lock

Re: [PATCH tip/core/rcu 1/9] rcu: Provide GP ordering in face of migrations and delays

2017-10-05 Thread Paul E. McKenney
On Thu, Oct 05, 2017 at 06:25:14PM +0200, Peter Zijlstra wrote: > On Thu, Oct 05, 2017 at 09:19:09AM -0700, Paul E. McKenney wrote: > > > > Yes, the ordering does need to be visible to uninvolved CPUs, so > > release-acquire is not necessarily strong enough. > > Why? Because I'm not at all

Re: [PATCH tip/core/rcu 1/9] rcu: Provide GP ordering in face of migrations and delays

2017-10-05 Thread Paul E. McKenney
On Thu, Oct 05, 2017 at 06:25:14PM +0200, Peter Zijlstra wrote: > On Thu, Oct 05, 2017 at 09:19:09AM -0700, Paul E. McKenney wrote: > > > > Yes, the ordering does need to be visible to uninvolved CPUs, so > > release-acquire is not necessarily strong enough. > > Why? Because I'm not at all

Re: [PATCH tip/core/rcu 1/9] rcu: Provide GP ordering in face of migrations and delays

2017-10-05 Thread Peter Zijlstra
On Thu, Oct 05, 2017 at 09:19:09AM -0700, Paul E. McKenney wrote: > > Yes, the ordering does need to be visible to uninvolved CPUs, so > release-acquire is not necessarily strong enough. Why? Because I'm not at all seeing why it needs more. Your Changelog doesn't provide enough hints.

Re: [PATCH tip/core/rcu 1/9] rcu: Provide GP ordering in face of migrations and delays

2017-10-05 Thread Peter Zijlstra
On Thu, Oct 05, 2017 at 09:19:09AM -0700, Paul E. McKenney wrote: > > Yes, the ordering does need to be visible to uninvolved CPUs, so > release-acquire is not necessarily strong enough. Why? Because I'm not at all seeing why it needs more. Your Changelog doesn't provide enough hints.

Re: [PATCH tip/core/rcu 1/9] rcu: Provide GP ordering in face of migrations and delays

2017-10-05 Thread Paul E. McKenney
On Thu, Oct 05, 2017 at 05:39:13PM +0200, Peter Zijlstra wrote: > On Thu, Oct 05, 2017 at 07:55:13AM -0700, Paul E. McKenney wrote: > > On Thu, Oct 05, 2017 at 11:41:14AM +0200, Peter Zijlstra wrote: > > > On Wed, Oct 04, 2017 at 02:29:27PM -0700, Paul E. McKenney wrote: > > > > Consider the

Re: [PATCH tip/core/rcu 1/9] rcu: Provide GP ordering in face of migrations and delays

2017-10-05 Thread Paul E. McKenney
On Thu, Oct 05, 2017 at 05:39:13PM +0200, Peter Zijlstra wrote: > On Thu, Oct 05, 2017 at 07:55:13AM -0700, Paul E. McKenney wrote: > > On Thu, Oct 05, 2017 at 11:41:14AM +0200, Peter Zijlstra wrote: > > > On Wed, Oct 04, 2017 at 02:29:27PM -0700, Paul E. McKenney wrote: > > > > Consider the

Re: [PATCH tip/core/rcu 1/9] rcu: Provide GP ordering in face of migrations and delays

2017-10-05 Thread Peter Zijlstra
On Thu, Oct 05, 2017 at 07:55:13AM -0700, Paul E. McKenney wrote: > On Thu, Oct 05, 2017 at 11:41:14AM +0200, Peter Zijlstra wrote: > > On Wed, Oct 04, 2017 at 02:29:27PM -0700, Paul E. McKenney wrote: > > > Consider the following admittedly improbable sequence of events: > > > > > > o RCU is

Re: [PATCH tip/core/rcu 1/9] rcu: Provide GP ordering in face of migrations and delays

2017-10-05 Thread Peter Zijlstra
On Thu, Oct 05, 2017 at 07:55:13AM -0700, Paul E. McKenney wrote: > On Thu, Oct 05, 2017 at 11:41:14AM +0200, Peter Zijlstra wrote: > > On Wed, Oct 04, 2017 at 02:29:27PM -0700, Paul E. McKenney wrote: > > > Consider the following admittedly improbable sequence of events: > > > > > > o RCU is

Re: [PATCH tip/core/rcu 1/9] rcu: Provide GP ordering in face of migrations and delays

2017-10-05 Thread Paul E. McKenney
On Thu, Oct 05, 2017 at 11:41:14AM +0200, Peter Zijlstra wrote: > On Wed, Oct 04, 2017 at 02:29:27PM -0700, Paul E. McKenney wrote: > > Consider the following admittedly improbable sequence of events: > > > > o RCU is initially idle. > > > > o Task A on CPU 0 executes rcu_read_lock(). > > >

Re: [PATCH tip/core/rcu 1/9] rcu: Provide GP ordering in face of migrations and delays

2017-10-05 Thread Paul E. McKenney
On Thu, Oct 05, 2017 at 11:41:14AM +0200, Peter Zijlstra wrote: > On Wed, Oct 04, 2017 at 02:29:27PM -0700, Paul E. McKenney wrote: > > Consider the following admittedly improbable sequence of events: > > > > o RCU is initially idle. > > > > o Task A on CPU 0 executes rcu_read_lock(). > > >

Re: [PATCH tip/core/rcu 1/9] rcu: Provide GP ordering in face of migrations and delays

2017-10-05 Thread Steven Rostedt
On Thu, 5 Oct 2017 15:40:42 +0200 Peter Zijlstra wrote: > On Thu, Oct 05, 2017 at 09:17:03AM -0400, Steven Rostedt wrote: > > On Wed, 4 Oct 2017 14:29:27 -0700 > > "Paul E. McKenney" wrote: > > > > > Consider the following admittedly

Re: [PATCH tip/core/rcu 1/9] rcu: Provide GP ordering in face of migrations and delays

2017-10-05 Thread Steven Rostedt
On Thu, 5 Oct 2017 15:40:42 +0200 Peter Zijlstra wrote: > On Thu, Oct 05, 2017 at 09:17:03AM -0400, Steven Rostedt wrote: > > On Wed, 4 Oct 2017 14:29:27 -0700 > > "Paul E. McKenney" wrote: > > > > > Consider the following admittedly improbable sequence of events: > > > > > > o RCU is

Re: [PATCH tip/core/rcu 1/9] rcu: Provide GP ordering in face of migrations and delays

2017-10-05 Thread Peter Zijlstra
On Thu, Oct 05, 2017 at 09:17:03AM -0400, Steven Rostedt wrote: > On Wed, 4 Oct 2017 14:29:27 -0700 > "Paul E. McKenney" wrote: > > > Consider the following admittedly improbable sequence of events: > > > > o RCU is initially idle. > > > > o Task A on CPU 0

Re: [PATCH tip/core/rcu 1/9] rcu: Provide GP ordering in face of migrations and delays

2017-10-05 Thread Peter Zijlstra
On Thu, Oct 05, 2017 at 09:17:03AM -0400, Steven Rostedt wrote: > On Wed, 4 Oct 2017 14:29:27 -0700 > "Paul E. McKenney" wrote: > > > Consider the following admittedly improbable sequence of events: > > > > o RCU is initially idle. > > > > o Task A on CPU 0 executes rcu_read_lock(). > >

Re: [PATCH tip/core/rcu 1/9] rcu: Provide GP ordering in face of migrations and delays

2017-10-05 Thread Steven Rostedt
On Wed, 4 Oct 2017 14:29:27 -0700 "Paul E. McKenney" wrote: > Consider the following admittedly improbable sequence of events: > > o RCU is initially idle. > > o Task A on CPU 0 executes rcu_read_lock(). A starts rcu_read_lock() critical section. > > o

Re: [PATCH tip/core/rcu 1/9] rcu: Provide GP ordering in face of migrations and delays

2017-10-05 Thread Steven Rostedt
On Wed, 4 Oct 2017 14:29:27 -0700 "Paul E. McKenney" wrote: > Consider the following admittedly improbable sequence of events: > > o RCU is initially idle. > > o Task A on CPU 0 executes rcu_read_lock(). A starts rcu_read_lock() critical section. > > o Task B on CPU 1 executes

Re: [PATCH tip/core/rcu 1/9] rcu: Provide GP ordering in face of migrations and delays

2017-10-05 Thread Peter Zijlstra
On Wed, Oct 04, 2017 at 02:29:27PM -0700, Paul E. McKenney wrote: > Consider the following admittedly improbable sequence of events: > > o RCU is initially idle. > > o Task A on CPU 0 executes rcu_read_lock(). > > o Task B on CPU 1 executes synchronize_rcu(), which must > wait

Re: [PATCH tip/core/rcu 1/9] rcu: Provide GP ordering in face of migrations and delays

2017-10-05 Thread Peter Zijlstra
On Wed, Oct 04, 2017 at 02:29:27PM -0700, Paul E. McKenney wrote: > Consider the following admittedly improbable sequence of events: > > o RCU is initially idle. > > o Task A on CPU 0 executes rcu_read_lock(). > > o Task B on CPU 1 executes synchronize_rcu(), which must > wait