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
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
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
> co
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
> > > > wait_for_completi
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() / wai
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
> > >
> >
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)
> > {
> >
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)
> > {
> >
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 acquisiti
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 seeing
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.
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 follow
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 init
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().
> >
>
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 initi
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().
>
> A
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 s
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
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 on Task A:
o Task B registers the callback, which starts a
19 matches
Mail list logo