From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> To: Tim Chen <tim.c.chen@linux.intel.com> Cc: Ingo Molnar <mingo@elte.hu>, Andrew Morton <akpm@linux-foundation.org>, Thomas Gleixner <tglx@linutronix.de>, linux-kernel@vger.kernel.org, linux-mm <linux-mm@kvack.org>, linux-arch@vger.kernel.org, Linus Torvalds <torvalds@linux-foundation.org>, Waiman Long <waiman.long@hp.com>, Andrea Arcangeli <aarcange@redhat.com>, Alex Shi <alex.shi@linaro.org>, Andi Kleen <andi@firstfloor.org>, Michel Lespinasse <walken@google.com>, Davidlohr Bueso <davidlohr.bueso@hp.com>, Matthew R Wilcox <matthew.r.wilcox@intel.com>, Dave Hansen <dave.hansen@intel.com>, Peter Zijlstra <a.p.zijlstra@chello.nl>, Rik van Riel <riel@redhat.com>, Peter Hurley <peter@hurleysoftware.com>, Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>, George Spelvin <linux@horizon.com>, "H. Peter Anvin" <hpa> Subject: Re: [PATCH v5 2/4] MCS Lock: optimizations and extra comments Date: Tue, 19 Nov 2013 11:13:10 -0800 [thread overview] Message-ID: <20131119191310.GO4138@linux.vnet.ibm.com> (raw) In-Reply-To: <1383940325.11046.415.camel@schen9-DESK> On Fri, Nov 08, 2013 at 11:52:05AM -0800, Tim Chen wrote: > From: Jason Low <jason.low2@hp.com> > > Remove unnecessary operation and make the cmpxchg(lock, node, NULL) == node > check in mcs_spin_unlock() likely() as it is likely that a race did not occur > most of the time. > > Also add in more comments describing how the local node is used in MCS locks. > > Reviewed-by: Tim Chen <tim.c.chen@linux.intel.com> > Signed-off-by: Jason Low <jason.low2@hp.com> > --- > 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 b5de3b0..96f14299 100644 > --- a/include/linux/mcs_spinlock.h > +++ b/include/linux/mcs_spinlock.h > @@ -18,6 +18,12 @@ struct mcs_spinlock { > }; > > /* > + * In order to acquire the lock, the caller should declare a local node and > + * pass a reference of the node to this function in addition to the lock. > + * If the lock has already been acquired, then this will proceed to spin > + * on this node->locked until the previous lock holder sets the node->locked > + * in mcs_spin_unlock(). > + * > * We don't inline mcs_spin_lock() so that perf can correctly account for the > * time spent in this lock function. > */ > @@ -33,7 +39,6 @@ void mcs_spin_lock(struct mcs_spinlock **lock, struct mcs_spinlock *node) > prev = xchg(lock, node); > if (likely(prev == NULL)) { > /* Lock acquired */ > - node->locked = 1; Agreed, no one looks at this field in this case, so no need to initialize it, unless for debug purposes. > return; > } > ACCESS_ONCE(prev->next) = node; > @@ -43,6 +48,10 @@ void mcs_spin_lock(struct mcs_spinlock **lock, struct mcs_spinlock *node) > arch_mutex_cpu_relax(); > } > > +/* > + * Releases the lock. The caller should pass in the corresponding node that > + * was used to acquire the lock. > + */ > static void mcs_spin_unlock(struct mcs_spinlock **lock, struct mcs_spinlock *node) > { > struct mcs_spinlock *next = ACCESS_ONCE(node->next); > @@ -51,7 +60,7 @@ static void mcs_spin_unlock(struct mcs_spinlock **lock, struct mcs_spinlock *nod > /* > * Release the lock by setting it to NULL > */ > - if (cmpxchg(lock, node, NULL) == node) > + if (likely(cmpxchg(lock, node, NULL) == node)) Agreed here as well. Takes a narrow race to hit this. So, did your testing exercise this path? If the answer is "yes", and if the issues that I called out in patch #1 are resolved: Reviewed-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> > return; > /* Wait until the next pointer is set */ > while (!(next = ACCESS_ONCE(node->next))) > -- > 1.7.4.4 > > > -- 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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> To: Tim Chen <tim.c.chen@linux.intel.com> Cc: Ingo Molnar <mingo@elte.hu>, Andrew Morton <akpm@linux-foundation.org>, Thomas Gleixner <tglx@linutronix.de>, linux-kernel@vger.kernel.org, linux-mm <linux-mm@kvack.org>, linux-arch@vger.kernel.org, Linus Torvalds <torvalds@linux-foundation.org>, Waiman Long <waiman.long@hp.com>, Andrea Arcangeli <aarcange@redhat.com>, Alex Shi <alex.shi@linaro.org>, Andi Kleen <andi@firstfloor.org>, Michel Lespinasse <walken@google.com>, Davidlohr Bueso <davidlohr.bueso@hp.com>, Matthew R Wilcox <matthew.r.wilcox@intel.com>, Dave Hansen <dave.hansen@intel.com>, Peter Zijlstra <a.p.zijlstra@chello.nl>, Rik van Riel <riel@redhat.com>, Peter Hurley <peter@hurleysoftware.com>, Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>, George Spelvin <linux@horizon.com>, "H. Peter Anvin" <hpa@zytor.com>, Arnd Bergmann <arnd@arndb.de>, Aswin Chandramouleeswaran <aswin@hp.com>, Scott J Norton <scott.norton@hp.com>, Will Deacon <will.deacon@arm.com>, "Figo.zhang" <figo1802@gmail.com> Subject: Re: [PATCH v5 2/4] MCS Lock: optimizations and extra comments Date: Tue, 19 Nov 2013 11:13:10 -0800 [thread overview] Message-ID: <20131119191310.GO4138@linux.vnet.ibm.com> (raw) Message-ID: <20131119191310.aSXbOegWvgBdg-GcqVWBzH3txoA-U0DqM31GB2AMY-s@z> (raw) In-Reply-To: <1383940325.11046.415.camel@schen9-DESK> On Fri, Nov 08, 2013 at 11:52:05AM -0800, Tim Chen wrote: > From: Jason Low <jason.low2@hp.com> > > Remove unnecessary operation and make the cmpxchg(lock, node, NULL) == node > check in mcs_spin_unlock() likely() as it is likely that a race did not occur > most of the time. > > Also add in more comments describing how the local node is used in MCS locks. > > Reviewed-by: Tim Chen <tim.c.chen@linux.intel.com> > Signed-off-by: Jason Low <jason.low2@hp.com> > --- > 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 b5de3b0..96f14299 100644 > --- a/include/linux/mcs_spinlock.h > +++ b/include/linux/mcs_spinlock.h > @@ -18,6 +18,12 @@ struct mcs_spinlock { > }; > > /* > + * In order to acquire the lock, the caller should declare a local node and > + * pass a reference of the node to this function in addition to the lock. > + * If the lock has already been acquired, then this will proceed to spin > + * on this node->locked until the previous lock holder sets the node->locked > + * in mcs_spin_unlock(). > + * > * We don't inline mcs_spin_lock() so that perf can correctly account for the > * time spent in this lock function. > */ > @@ -33,7 +39,6 @@ void mcs_spin_lock(struct mcs_spinlock **lock, struct mcs_spinlock *node) > prev = xchg(lock, node); > if (likely(prev == NULL)) { > /* Lock acquired */ > - node->locked = 1; Agreed, no one looks at this field in this case, so no need to initialize it, unless for debug purposes. > return; > } > ACCESS_ONCE(prev->next) = node; > @@ -43,6 +48,10 @@ void mcs_spin_lock(struct mcs_spinlock **lock, struct mcs_spinlock *node) > arch_mutex_cpu_relax(); > } > > +/* > + * Releases the lock. The caller should pass in the corresponding node that > + * was used to acquire the lock. > + */ > static void mcs_spin_unlock(struct mcs_spinlock **lock, struct mcs_spinlock *node) > { > struct mcs_spinlock *next = ACCESS_ONCE(node->next); > @@ -51,7 +60,7 @@ static void mcs_spin_unlock(struct mcs_spinlock **lock, struct mcs_spinlock *nod > /* > * Release the lock by setting it to NULL > */ > - if (cmpxchg(lock, node, NULL) == node) > + if (likely(cmpxchg(lock, node, NULL) == node)) Agreed here as well. Takes a narrow race to hit this. So, did your testing exercise this path? If the answer is "yes", and if the issues that I called out in patch #1 are resolved: Reviewed-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> > return; > /* Wait until the next pointer is set */ > while (!(next = ACCESS_ONCE(node->next))) > -- > 1.7.4.4 > > >
next prev parent reply other threads:[~2013-11-19 19:13 UTC|newest] Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <cover.1383935697.git.tim.c.chen@linux.intel.com> 2013-11-08 19:51 ` [PATCH v5 1/4] MCS Lock: Restructure the MCS lock defines and locking code into its own file Tim Chen 2013-11-08 19:51 ` Tim Chen 2013-11-19 19:10 ` Paul E. McKenney 2013-11-19 19:10 ` Paul E. McKenney 2013-11-19 19:42 ` Tim Chen 2013-11-19 19:42 ` Tim Chen 2013-11-19 19:54 ` Paul E. McKenney 2013-11-19 19:54 ` Paul E. McKenney 2013-11-08 19:52 ` [PATCH v5 2/4] MCS Lock: optimizations and extra comments Tim Chen 2013-11-08 19:52 ` Tim Chen 2013-11-19 19:13 ` Paul E. McKenney [this message] 2013-11-19 19:13 ` Paul E. McKenney 2013-11-19 19:42 ` Tim Chen 2013-11-19 19:42 ` Tim Chen 2013-11-19 22:57 ` Tim Chen 2013-11-19 22:57 ` Tim Chen 2013-11-19 23:05 ` Paul E. McKenney 2013-11-19 23:05 ` Paul E. McKenney 2013-11-08 19:52 ` [PATCH v5 3/4] MCS Lock: Move mcs_lock/unlock function into its own file Tim Chen 2013-11-08 19:52 ` Tim Chen 2013-11-19 19:15 ` Paul E. McKenney 2013-11-19 19:15 ` Paul E. McKenney 2013-11-08 19:52 ` [PATCH v5 4/4] MCS Lock: Barrier corrections Tim Chen 2013-11-08 19:52 ` Tim Chen 2013-11-11 18:10 ` Will Deacon 2013-11-11 18:20 ` Peter Zijlstra 2013-11-19 19:23 ` Paul E. McKenney 2013-11-11 21:17 ` Tim Chen 2013-11-12 1:57 ` Waiman Long 2013-11-19 19:32 ` Paul E. McKenney 2013-11-19 21:45 ` Tim Chen 2013-11-19 23:30 ` Paul E. McKenney 2013-11-12 2:09 ` Waiman Long 2013-11-12 14:54 ` Waiman Long 2013-11-12 14:54 ` Waiman Long 2013-11-12 16:08 ` Will Deacon 2013-11-12 17:16 ` George Spelvin 2013-11-13 17:37 ` Will Deacon 2013-11-19 19:26 ` Paul E. McKenney 2013-11-19 19:21 ` Paul E. McKenney 2013-11-19 19:21 ` Paul E. McKenney 2013-11-19 19:46 ` Tim Chen 2013-11-19 19:46 ` Tim Chen
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20131119191310.GO4138@linux.vnet.ibm.com \ --to=paulmck@linux.vnet.ibm.com \ --cc=a.p.zijlstra@chello.nl \ --cc=aarcange@redhat.com \ --cc=akpm@linux-foundation.org \ --cc=alex.shi@linaro.org \ --cc=andi@firstfloor.org \ --cc=dave.hansen@intel.com \ --cc=davidlohr.bueso@hp.com \ --cc=linux-arch@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=linux@horizon.com \ --cc=matthew.r.wilcox@intel.com \ --cc=mingo@elte.hu \ --cc=peter@hurleysoftware.com \ --cc=raghavendra.kt@linux.vnet.ibm.com \ --cc=riel@redhat.com \ --cc=tglx@linutronix.de \ --cc=tim.c.chen@linux.intel.com \ --cc=torvalds@linux-foundation.org \ --cc=waiman.long@hp.com \ --cc=walken@google.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).