From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Paul E. McKenney" Subject: Re: [PATCH v2 3/4] MCS Lock: Barrier corrections Date: Wed, 6 Nov 2013 06:45:20 -0800 Message-ID: <20131106144520.GK18245@linux.vnet.ibm.com> References: <1383673356.11046.279.camel@schen9-DESK> <20131105183744.GJ26895@mudshark.cambridge.arm.com> <1383679317.11046.293.camel@schen9-DESK> <20131105211803.GS28601@twins.programming.kicks-ass.net> Reply-To: paulmck@linux.vnet.ibm.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <20131105211803.GS28601@twins.programming.kicks-ass.net> Sender: owner-linux-mm@kvack.org To: Peter Zijlstra Cc: Tim Chen , Will Deacon , Ingo Molnar , Andrew Morton , Thomas Gleixner , "linux-kernel@vger.kernel.org" , linux-mm , "linux-arch@vger.kernel.org" , Linus Torvalds , Waiman Long , Andrea Arcangeli , Alex Shi , Andi Kleen , Michel Lespinasse , Davidlohr Bueso , Matthew R Wilcox , Dave Hansen , Rik van Riel , Peter Hurley , Raghavendra List-Id: linux-arch.vger.kernel.org On Tue, Nov 05, 2013 at 10:18:03PM +0100, Peter Zijlstra wrote: > On Tue, Nov 05, 2013 at 11:21:57AM -0800, Tim Chen wrote: > > On Tue, 2013-11-05 at 18:37 +0000, Will Deacon wrote: > > > On Tue, Nov 05, 2013 at 05:42:36PM +0000, Tim Chen wrote: > > > > This patch corrects the way memory barriers are used in the MCS lock > > > > and removes ones that are not needed. Also add comments on all barriers. > > > > > > Hmm, I see that you're fixing up the barriers, but I still don't completely > > > understand how what you have is correct. Hopefully you can help me out :) > > > > > > > Reviewed-by: Paul E. McKenney > > > > Reviewed-by: Tim Chen > > > > Signed-off-by: Jason Low > > > > --- > > > > include/linux/mcs_spinlock.h | 13 +++++++++++-- > > > > 1 files changed, 11 insertions(+), 2 deletions(-) > > > > > > > > diff --git a/include/linux/mcs_spinlock.h b/include/linux/mcs_spinlock.h > > > > index 96f14299..93d445d 100644 > > > > --- a/include/linux/mcs_spinlock.h > > > > +++ b/include/linux/mcs_spinlock.h > > > > @@ -36,16 +36,19 @@ void mcs_spin_lock(struct mcs_spinlock **lock, struct mcs_spinlock *node) > > > > node->locked = 0; > > > > node->next = NULL; > > > > > > > > + /* xchg() provides a memory barrier */ > > > > prev = xchg(lock, node); > > > > if (likely(prev == NULL)) { > > > > /* Lock acquired */ > > > > return; > > > > } > > > > ACCESS_ONCE(prev->next) = node; > > > > - smp_wmb(); > > > > /* Wait until the lock holder passes the lock down */ > > > > while (!ACCESS_ONCE(node->locked)) > > > > arch_mutex_cpu_relax(); > > > > + > > > > + /* Make sure subsequent operations happen after the lock is acquired */ > > > > + smp_rmb(); > > > > > > Ok, so this is an smp_rmb() because we assume that stores aren't speculated, > > > right? (i.e. the control dependency above is enough for stores to be ordered > > > with respect to taking the lock)... > > PaulMck completely confused me a few days ago with control dependencies > etc.. Pretty much saying that C/C++ doesn't do those. I remember that there was a subtlety here, but don't remember what it was... And while I do remember reviewing this code, I don't find any evidence that I gave my "Reviewed-by". Tim/Jason, if I fat-fingered this, please forward that email back to me. Thanx, Paul -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from e9.ny.us.ibm.com ([32.97.182.139]:38188 "EHLO e9.ny.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932500Ab3KFPHT (ORCPT ); Wed, 6 Nov 2013 10:07:19 -0500 Received: from /spool/local by e9.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 6 Nov 2013 10:07:18 -0500 Date: Wed, 6 Nov 2013 06:45:20 -0800 From: "Paul E. McKenney" Subject: Re: [PATCH v2 3/4] MCS Lock: Barrier corrections Message-ID: <20131106144520.GK18245@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com References: <1383673356.11046.279.camel@schen9-DESK> <20131105183744.GJ26895@mudshark.cambridge.arm.com> <1383679317.11046.293.camel@schen9-DESK> <20131105211803.GS28601@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131105211803.GS28601@twins.programming.kicks-ass.net> Sender: linux-arch-owner@vger.kernel.org List-ID: To: Peter Zijlstra Cc: Tim Chen , Will Deacon , Ingo Molnar , Andrew Morton , Thomas Gleixner , "linux-kernel@vger.kernel.org" , linux-mm , "linux-arch@vger.kernel.org" , Linus Torvalds , Waiman Long , Andrea Arcangeli , Alex Shi , Andi Kleen , Michel Lespinasse , Davidlohr Bueso , Matthew R Wilcox , Dave Hansen , Rik van Riel , Peter Hurley , Raghavendra K T , George Spelvin , "H. Peter Anvin" , Arnd Bergmann , Aswin Chandramouleeswaran , Scott J Norton Message-ID: <20131106144520.5ozbbf2eBw28rHrEGqXa6sT-aNN9VxmOgYDQ_XYlsgQ@z> On Tue, Nov 05, 2013 at 10:18:03PM +0100, Peter Zijlstra wrote: > On Tue, Nov 05, 2013 at 11:21:57AM -0800, Tim Chen wrote: > > On Tue, 2013-11-05 at 18:37 +0000, Will Deacon wrote: > > > On Tue, Nov 05, 2013 at 05:42:36PM +0000, Tim Chen wrote: > > > > This patch corrects the way memory barriers are used in the MCS lock > > > > and removes ones that are not needed. Also add comments on all barriers. > > > > > > Hmm, I see that you're fixing up the barriers, but I still don't completely > > > understand how what you have is correct. Hopefully you can help me out :) > > > > > > > Reviewed-by: Paul E. McKenney > > > > Reviewed-by: Tim Chen > > > > Signed-off-by: Jason Low > > > > --- > > > > include/linux/mcs_spinlock.h | 13 +++++++++++-- > > > > 1 files changed, 11 insertions(+), 2 deletions(-) > > > > > > > > diff --git a/include/linux/mcs_spinlock.h b/include/linux/mcs_spinlock.h > > > > index 96f14299..93d445d 100644 > > > > --- a/include/linux/mcs_spinlock.h > > > > +++ b/include/linux/mcs_spinlock.h > > > > @@ -36,16 +36,19 @@ void mcs_spin_lock(struct mcs_spinlock **lock, struct mcs_spinlock *node) > > > > node->locked = 0; > > > > node->next = NULL; > > > > > > > > + /* xchg() provides a memory barrier */ > > > > prev = xchg(lock, node); > > > > if (likely(prev == NULL)) { > > > > /* Lock acquired */ > > > > return; > > > > } > > > > ACCESS_ONCE(prev->next) = node; > > > > - smp_wmb(); > > > > /* Wait until the lock holder passes the lock down */ > > > > while (!ACCESS_ONCE(node->locked)) > > > > arch_mutex_cpu_relax(); > > > > + > > > > + /* Make sure subsequent operations happen after the lock is acquired */ > > > > + smp_rmb(); > > > > > > Ok, so this is an smp_rmb() because we assume that stores aren't speculated, > > > right? (i.e. the control dependency above is enough for stores to be ordered > > > with respect to taking the lock)... > > PaulMck completely confused me a few days ago with control dependencies > etc.. Pretty much saying that C/C++ doesn't do those. I remember that there was a subtlety here, but don't remember what it was... And while I do remember reviewing this code, I don't find any evidence that I gave my "Reviewed-by". Tim/Jason, if I fat-fingered this, please forward that email back to me. Thanx, Paul