Re: [PATCH 10/10] locking/qspinlock: Elide back-to-back RELEASE operations with smp_wmb()

2018-04-09 Thread Will Deacon
Hi Boqun, On Sat, Apr 07, 2018 at 01:47:11PM +0800, Boqun Feng wrote: > On Thu, Apr 05, 2018 at 05:59:07PM +0100, Will Deacon wrote: > > @@ -340,12 +341,17 @@ void queued_spin_lock_slowpath(struct qspinlock > > *lock, u32 val) > > goto release; > > > > /* > > +* Ensure that

Re: [PATCH 10/10] locking/qspinlock: Elide back-to-back RELEASE operations with smp_wmb()

2018-04-09 Thread Will Deacon
Hi Boqun, On Sat, Apr 07, 2018 at 01:47:11PM +0800, Boqun Feng wrote: > On Thu, Apr 05, 2018 at 05:59:07PM +0100, Will Deacon wrote: > > @@ -340,12 +341,17 @@ void queued_spin_lock_slowpath(struct qspinlock > > *lock, u32 val) > > goto release; > > > > /* > > +* Ensure that

Re: [PATCH 10/10] locking/qspinlock: Elide back-to-back RELEASE operations with smp_wmb()

2018-04-06 Thread Boqun Feng
On Thu, Apr 05, 2018 at 05:59:07PM +0100, Will Deacon wrote: > The qspinlock slowpath must ensure that the MCS node is fully initialised > before it can be reached by another other CPU. This is currently enforced > by using a RELEASE operation when updating the tail and also when linking > the

Re: [PATCH 10/10] locking/qspinlock: Elide back-to-back RELEASE operations with smp_wmb()

2018-04-06 Thread Boqun Feng
On Thu, Apr 05, 2018 at 05:59:07PM +0100, Will Deacon wrote: > The qspinlock slowpath must ensure that the MCS node is fully initialised > before it can be reached by another other CPU. This is currently enforced > by using a RELEASE operation when updating the tail and also when linking > the

Re: [PATCH 10/10] locking/qspinlock: Elide back-to-back RELEASE operations with smp_wmb()

2018-04-06 Thread Andrea Parri
On Fri, Apr 06, 2018 at 04:27:45PM +0100, Will Deacon wrote: > Hi Andrea, > > On Fri, Apr 06, 2018 at 03:05:12PM +0200, Andrea Parri wrote: > > On Fri, Apr 06, 2018 at 12:34:36PM +0100, Will Deacon wrote: > > > I could say something like: > > > > > > "Pairs with dependency ordering from both

Re: [PATCH 10/10] locking/qspinlock: Elide back-to-back RELEASE operations with smp_wmb()

2018-04-06 Thread Andrea Parri
On Fri, Apr 06, 2018 at 04:27:45PM +0100, Will Deacon wrote: > Hi Andrea, > > On Fri, Apr 06, 2018 at 03:05:12PM +0200, Andrea Parri wrote: > > On Fri, Apr 06, 2018 at 12:34:36PM +0100, Will Deacon wrote: > > > I could say something like: > > > > > > "Pairs with dependency ordering from both

Re: [PATCH 10/10] locking/qspinlock: Elide back-to-back RELEASE operations with smp_wmb()

2018-04-06 Thread Will Deacon
Hi Andrea, On Fri, Apr 06, 2018 at 03:05:12PM +0200, Andrea Parri wrote: > On Fri, Apr 06, 2018 at 12:34:36PM +0100, Will Deacon wrote: > > I could say something like: > > > > "Pairs with dependency ordering from both xchg_tail and explicit > >dereferences of node->next" > > > > but it's

Re: [PATCH 10/10] locking/qspinlock: Elide back-to-back RELEASE operations with smp_wmb()

2018-04-06 Thread Will Deacon
Hi Andrea, On Fri, Apr 06, 2018 at 03:05:12PM +0200, Andrea Parri wrote: > On Fri, Apr 06, 2018 at 12:34:36PM +0100, Will Deacon wrote: > > I could say something like: > > > > "Pairs with dependency ordering from both xchg_tail and explicit > >dereferences of node->next" > > > > but it's

Re: [PATCH 10/10] locking/qspinlock: Elide back-to-back RELEASE operations with smp_wmb()

2018-04-06 Thread Andrea Parri
Hi Will, On Fri, Apr 06, 2018 at 12:34:36PM +0100, Will Deacon wrote: > On Thu, Apr 05, 2018 at 07:28:08PM +0200, Peter Zijlstra wrote: > > On Thu, Apr 05, 2018 at 05:59:07PM +0100, Will Deacon wrote: > > > @@ -340,12 +341,17 @@ void queued_spin_lock_slowpath(struct qspinlock > > > *lock, u32

Re: [PATCH 10/10] locking/qspinlock: Elide back-to-back RELEASE operations with smp_wmb()

2018-04-06 Thread Andrea Parri
Hi Will, On Fri, Apr 06, 2018 at 12:34:36PM +0100, Will Deacon wrote: > On Thu, Apr 05, 2018 at 07:28:08PM +0200, Peter Zijlstra wrote: > > On Thu, Apr 05, 2018 at 05:59:07PM +0100, Will Deacon wrote: > > > @@ -340,12 +341,17 @@ void queued_spin_lock_slowpath(struct qspinlock > > > *lock, u32

Re: [PATCH 10/10] locking/qspinlock: Elide back-to-back RELEASE operations with smp_wmb()

2018-04-06 Thread Will Deacon
On Thu, Apr 05, 2018 at 07:28:08PM +0200, Peter Zijlstra wrote: > On Thu, Apr 05, 2018 at 05:59:07PM +0100, Will Deacon wrote: > > @@ -340,12 +341,17 @@ void queued_spin_lock_slowpath(struct qspinlock > > *lock, u32 val) > > goto release; > > > > /* > > +* Ensure that the

Re: [PATCH 10/10] locking/qspinlock: Elide back-to-back RELEASE operations with smp_wmb()

2018-04-06 Thread Will Deacon
On Thu, Apr 05, 2018 at 07:28:08PM +0200, Peter Zijlstra wrote: > On Thu, Apr 05, 2018 at 05:59:07PM +0100, Will Deacon wrote: > > @@ -340,12 +341,17 @@ void queued_spin_lock_slowpath(struct qspinlock > > *lock, u32 val) > > goto release; > > > > /* > > +* Ensure that the

Re: [PATCH 10/10] locking/qspinlock: Elide back-to-back RELEASE operations with smp_wmb()

2018-04-05 Thread Peter Zijlstra
On Thu, Apr 05, 2018 at 05:59:07PM +0100, Will Deacon wrote: > @@ -340,12 +341,17 @@ void queued_spin_lock_slowpath(struct qspinlock *lock, > u32 val) > goto release; > > /* > + * Ensure that the initialisation of @node is complete before we > + * publish the

Re: [PATCH 10/10] locking/qspinlock: Elide back-to-back RELEASE operations with smp_wmb()

2018-04-05 Thread Peter Zijlstra
On Thu, Apr 05, 2018 at 05:59:07PM +0100, Will Deacon wrote: > @@ -340,12 +341,17 @@ void queued_spin_lock_slowpath(struct qspinlock *lock, > u32 val) > goto release; > > /* > + * Ensure that the initialisation of @node is complete before we > + * publish the