linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
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>,
	"Paul E.McKenney" <paulmck@linux.vnet.ibm.com>,
	Will Deacon <will.deacon@arm.com>,
	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>,
	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>,
	"Figo.zhang" <figo1802@gmail.com>
Subject: Re: [PATCH v7 2/6] MCS Lock: optimizations and extra comments
Date: Mon, 20 Jan 2014 14:58:03 +0100	[thread overview]
Message-ID: <20140120135803.GF31570@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <1389917300.3138.12.camel@schen9-DESK>

On Thu, Jan 16, 2014 at 04:08:20PM -0800, Tim Chen wrote:
> 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.

It might be good to describe why the node->locked=1 is thought
unnecessary. I concur it is, but upon reading this changelog I was left
wondering and had to go read the code and run through the logic to
convince myself.

Having done so, I'm now wondering if we think so for the same reason --
although I'm fairly sure we are.

The argument goes like: everybody only looks at his own ->locked value,
therefore the only one possibly interested in node->locked is the lock
owner. However the lock owner doesn't care what's in it, it simply
assumes its 1 but really doesn't care one way or another.

That said, a possible DEBUG mode might want to actually set it, validate
that all other linked nodes are 0 and upon unlock verify the same before
flipping next->locked to 1.


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

  parent reply	other threads:[~2014-01-20 13:58 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <cover.1389890175.git.tim.c.chen@linux.intel.com>
2014-01-17  0:08 ` [PATCH v7 0/6] MCS Lock: MCS lock code cleanup and optimizations Tim Chen
2014-01-20 13:58   ` Peter Zijlstra
2014-01-20 14:22     ` Ingo Molnar
2014-01-17  0:08 ` [PATCH v7 1/6] MCS Lock: Restructure the MCS lock defines and locking code into its own file Tim Chen
2014-01-20  2:28   ` Paul E. McKenney
2014-01-20 12:07   ` Peter Zijlstra
2014-01-20 19:31     ` Tim Chen
2014-01-17  0:08 ` [PATCH v7 2/6] MCS Lock: optimizations and extra comments Tim Chen
2014-01-20  2:29   ` Paul E. McKenney
2014-01-20 13:58   ` Peter Zijlstra [this message]
2014-01-20 19:11     ` Tim Chen
2014-01-17  0:08 ` [PATCH v7 3/6] MCS Lock: Move mcs_lock/unlock function into its own file Tim Chen
2014-01-20  2:32   ` Paul E. McKenney
2014-01-20 12:15   ` Peter Zijlstra
2014-01-17  0:08 ` [PATCH v7 4/6] MCS Lock: Barrier corrections Tim Chen
2014-01-20  2:33   ` Paul E. McKenney
2014-01-20  7:09     ` Ingo Molnar
2014-01-17  0:08 ` [PATCH v7 5/6] MCS Lock: allow architectures to hook in to contended paths Tim Chen
2014-01-20  2:34   ` Paul E. McKenney
2014-01-20 12:19   ` Peter Zijlstra
2014-01-20 14:11     ` Will Deacon
2014-01-20 16:43       ` Tim Chen
2014-01-17  0:08 ` [PATCH v7 6/6] MCS Lock: add Kconfig entries to allow arch-specific hooks Tim Chen
2014-01-20  2:35   ` Paul E. McKenney
2014-01-20 12:30   ` Peter Zijlstra
2014-01-20 12:35     ` Geert Uytterhoeven
2014-01-20 12:36       ` Peter Zijlstra
2014-01-20 12:38         ` Ingo Molnar
2014-01-20 13:17     ` Peter Zijlstra
2014-01-20 23:31     ` Tim Chen
2014-01-21  9:47       ` Peter Zijlstra

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=20140120135803.GF31570@twins.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=alex.shi@linaro.org \
    --cc=andi@firstfloor.org \
    --cc=arnd@arndb.de \
    --cc=aswin@hp.com \
    --cc=dave.hansen@intel.com \
    --cc=davidlohr.bueso@hp.com \
    --cc=figo1802@gmail.com \
    --cc=hpa@zytor.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=paulmck@linux.vnet.ibm.com \
    --cc=peter@hurleysoftware.com \
    --cc=raghavendra.kt@linux.vnet.ibm.com \
    --cc=riel@redhat.com \
    --cc=scott.norton@hp.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 \
    --cc=will.deacon@arm.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: link
Be 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