From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by kanga.kvack.org (Postfix) with ESMTP id 433E66B00BD for ; Wed, 6 Nov 2013 00:44:46 -0500 (EST) Received: by mail-pb0-f54.google.com with SMTP id ro12so3047201pbb.13 for ; Tue, 05 Nov 2013 21:44:45 -0800 (PST) Received: from psmtp.com ([74.125.245.196]) by mx.google.com with SMTP id sd2si15910430pbb.19.2013.11.05.21.44.44 for ; Tue, 05 Nov 2013 21:44:44 -0800 (PST) Received: by mail-oa0-f48.google.com with SMTP id h16so1659062oag.7 for ; Tue, 05 Nov 2013 21:44:42 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <1383679317.11046.293.camel@schen9-DESK> References: <1383673356.11046.279.camel@schen9-DESK> <20131105183744.GJ26895@mudshark.cambridge.arm.com> <1383679317.11046.293.camel@schen9-DESK> Date: Wed, 6 Nov 2013 13:44:42 +0800 Message-ID: Subject: Re: [PATCH v2 3/4] MCS Lock: Barrier corrections From: "Figo.zhang" Content-Type: multipart/alternative; boundary=047d7b33d176569b1704ea7ba57e Sender: owner-linux-mm@kvack.org List-ID: To: Tim Chen Cc: 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 , Peter Zijlstra , Rik van Riel , Peter Hurley , "Paul E.McKenney" , Raghavendra K T , George Spelvin , "H. Peter Anvin" , Arnd Bergmann , Aswin Chandramouleeswaran , Scott J Norton --047d7b33d176569b1704ea7ba57e Content-Type: text/plain; charset=ISO-8859-1 2013/11/6 Tim Chen > 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)... > > > > > } > > > > > > /* > > > @@ -58,6 +61,7 @@ static void mcs_spin_unlock(struct mcs_spinlock > **lock, struct mcs_spinlock *nod > > > > > > if (likely(!next)) { > > > /* > > > + * cmpxchg() provides a memory barrier. > > > * Release the lock by setting it to NULL > > > */ > > > if (likely(cmpxchg(lock, node, NULL) == node)) > > > @@ -65,9 +69,14 @@ static void mcs_spin_unlock(struct mcs_spinlock > **lock, struct mcs_spinlock *nod > > > /* Wait until the next pointer is set */ > > > while (!(next = ACCESS_ONCE(node->next))) > > > arch_mutex_cpu_relax(); > > > + } else { > > > + /* > > > + * Make sure all operations within the critical section > > > + * happen before the lock is released. > > > + */ > > > + smp_wmb(); > > > > ...but I don't see what prevents reads inside the critical section from > > moving across the smp_wmb() here. > > This is to prevent any read in next critical section from > creeping up before write in the previous critical section > has completed > > e.g. > CPU 1 execute > mcs_lock > x = 1; > ... > x = 2; > mcs_unlock > > and CPU 2 execute > > mcs_lock > y = x; > ... > mcs_unlock > > We expect y to be 2 after the "y = x" assignment. Without the proper > rmb in lock and wmb in unlock, y could be 1 for CPU 2 with > speculative read (i.e. before the x=2 assignment is completed). > is it not a good example ? why CPU2 will be waited the "x" set to "2" ? Maybe "y=x" assignment will be executed firstly than CPU1 in pipeline because of out-of-reorder. e.g. CPU 1 execute mcs_lock x = 1; ... x = 2; flags = true; mcs_unlock and CPU 2 execute while (flags) { mcs_lock y = x; ... mcs_unlock } --047d7b33d176569b1704ea7ba57e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



2013/11/6 Tim Chen <tim.c.chen@linux.intel.com>
On Tue, 2013-11-05 at 18:37 +0000, Will D= eacon 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 l= ock
> > and removes ones that are not needed. Also add comments on all ba= rriers.
>
> 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 <paulmck@linux.vnet.ibm.com>
> > Reviewed-by: Tim Chen <tim.c.chen@linux.intel.com>
> > Signed-off-by: Jason Low <jason.low2@hp.com>
> > ---
> > =A0include/linux/mcs_spinlock.h | =A0 13 +++++++++++--
> > =A01 files changed, 11 insertions(+), 2 deletions(-)
> >
> > diff --git a/include/linux/mcs_spinlock.h b/include/linux/mcs_spi= nlock.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)
> > =A0 =A0 node->locked =3D 0;
> > =A0 =A0 node->next =A0 =3D NULL;
> >
> > + =A0 /* xchg() provides a memory barrier */
> > =A0 =A0 prev =3D xchg(lock, node);
> > =A0 =A0 if (likely(prev =3D=3D NULL)) {
> > =A0 =A0 =A0 =A0 =A0 =A0 /* Lock acquired */
> > =A0 =A0 =A0 =A0 =A0 =A0 return;
> > =A0 =A0 }
> > =A0 =A0 ACCESS_ONCE(prev->next) =3D node;
> > - =A0 smp_wmb();
> > =A0 =A0 /* Wait until the lock holder passes the lock down */
> > =A0 =A0 while (!ACCESS_ONCE(node->locked))
> > =A0 =A0 =A0 =A0 =A0 =A0 arch_mutex_cpu_relax();
> > +
> > + =A0 /* Make sure subsequent operations happen after the lock is= acquired */
> > + =A0 smp_rmb();
>
> Ok, so this is an smp_rmb() because we assume that stores aren't s= peculated,
> right? (i.e. the control dependency above is enough for stores to be o= rdered
> with respect to taking the lock)...
>
> > =A0}
> >
> > =A0/*
> > @@ -58,6 +61,7 @@ static void mcs_spin_unlock(struct mcs_spinlock= **lock, struct mcs_spinlock *nod
> >
> > =A0 =A0 if (likely(!next)) {
> > =A0 =A0 =A0 =A0 =A0 =A0 /*
> > + =A0 =A0 =A0 =A0 =A0 =A0* cmpxchg() provides a memory barrier. > > =A0 =A0 =A0 =A0 =A0 =A0 =A0* Release the lock by setting it to NU= LL
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0*/
> > =A0 =A0 =A0 =A0 =A0 =A0 if (likely(cmpxchg(lock, node, NULL) =3D= =3D node))
> > @@ -65,9 +69,14 @@ static void mcs_spin_unlock(struct mcs_spinloc= k **lock, struct mcs_spinlock *nod
> > =A0 =A0 =A0 =A0 =A0 =A0 /* Wait until the next pointer is set */<= br> > > =A0 =A0 =A0 =A0 =A0 =A0 while (!(next =3D ACCESS_ONCE(node->ne= xt)))
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 arch_mutex_cpu_relax(); > > + =A0 } else {
> > + =A0 =A0 =A0 =A0 =A0 /*
> > + =A0 =A0 =A0 =A0 =A0 =A0* Make sure all operations within the cr= itical section
> > + =A0 =A0 =A0 =A0 =A0 =A0* happen before the lock is released. > > + =A0 =A0 =A0 =A0 =A0 =A0*/
> > + =A0 =A0 =A0 =A0 =A0 smp_wmb();
>
> ...but I don't see what prevents reads inside the critical section= from
> moving across the smp_wmb() here.

This is to prevent any read in next critical section from
creeping up before write in the previous critical section
has completed

e.g.
CPU 1 execute
=A0 =A0 =A0 =A0 mcs_lock
=A0 =A0 =A0 =A0 x =3D 1;
=A0 =A0 =A0 =A0 ...
=A0 =A0 =A0 =A0 x =3D 2;
=A0 =A0 =A0 =A0 mcs_unlock

and CPU 2 execute

=A0 =A0 =A0 =A0 mcs_lock
=A0 =A0 =A0 =A0 y =3D x;
=A0 =A0 =A0 =A0 ...
=A0 =A0 =A0 =A0 mcs_unlock

We expect y to be 2 after the "y =3D x" assignment. Without the p= roper
rmb in lock and wmb in unlock, y could be 1 for CPU 2 with
speculative read (i.e. before the x=3D2 assignment is completed).

is it not a good example ? =A0
why CPU= 2 will be waited =A0the "x" set to "2" ? =A0Maybe "= ;y=3Dx" assignment will be executed firstly than CPU1 in pipeline=A0
because of out-of-reorder.

e.g.
CPU 1 exec= ute
=A0 =A0 =A0 =A0 mcs_lock
=A0 =A0 =A0 =A0 x =3D 1;
=A0 =A0 =A0 = =A0 ...
=A0 =A0 =A0 =A0 x =3D 2;
=A0 =A0 =A0 =A0 flags =3D tru= e;
=A0 =A0 =A0 =A0 mcs_unlock

and CPU 2 execute

=A0 =A0 =A0 =A0while (flags) {
=A0 =A0 =A0 =A0 =A0 =A0 =A0 mcs_lock<= br>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0y =3D x;
=A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 ...
=A0 =A0 =A0 =A0 =A0 =A0 =A0 mcs_unlock
=A0 =A0 =A0= =A0}
=A0

--047d7b33d176569b1704ea7ba57e-- -- 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