From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Steven Rostedt <rostedt@goodmis.org>,
Alexander Fyodorov <halcy@yandex.ru>,
Waiman Long <waiman.long@hp.com>,
linux-kernel <linux-kernel@vger.kernel.org>,
"Chandramouleeswaran, Aswin" <aswin@hp.com>,
"Norton, Scott J" <scott.norton@hp.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>
Subject: Re: [PATCH RFC v2 1/2] qspinlock: Introducing a 4-byte queue spinlock implementation
Date: Tue, 27 Aug 2013 18:21:29 -0700 [thread overview]
Message-ID: <20130828012128.GT3871@linux.vnet.ibm.com> (raw)
In-Reply-To: <20130827135309.GF10002@twins.programming.kicks-ass.net>
On Tue, Aug 27, 2013 at 03:53:10PM +0200, Peter Zijlstra wrote:
> On Tue, Aug 27, 2013 at 09:14:36AM -0400, Steven Rostedt wrote:
>
> > I just had this conversation with Paul McKenney. Should there be a
> > smp_mb_after_spin_unlock()?
>
> Depends on the benefits I suppose :-) Oleg and Linus did recently add
> smp_mb__before_spinlock();
>
> > Although we blew it off as adding too many extensions to smp_mb(). But
> > it may be better than reimplementing something as complex as a lock.
>
> Locks should be as light weight as possible and never implement anything
> heavier than the ACQUISITION / RELEASE barriers if at all possible. We
> should certainly not re-implement spinlocks just to get full barriers
> out of them, that's crazy.
An unlock followed by a lock needs to act like a full barrier, but there
is no requirement that a lock or unlock taken separately act like a
full barrier.
Thanx, Paul
next prev parent reply other threads:[~2013-08-28 2:38 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <15321377012704@web8h.yandex.ru>
2013-08-21 3:01 ` [PATCH RFC v2 1/2] qspinlock: Introducing a 4-byte queue spinlock implementation Waiman Long
2013-08-21 15:51 ` Alexander Fyodorov
2013-08-22 1:04 ` Waiman Long
2013-08-22 13:28 ` Alexander Fyodorov
2013-08-26 20:14 ` Waiman Long
2013-08-27 12:09 ` Alexander Fyodorov
[not found] ` <20130827091436.3d5971a0@gandalf.local.home>
2013-08-27 13:53 ` Peter Zijlstra
2013-08-28 1:21 ` Paul E. McKenney [this message]
2013-08-28 8:19 ` Peter Zijlstra
2013-08-28 12:59 ` Steven Rostedt
2013-08-28 13:05 ` Peter Zijlstra
2013-08-28 13:15 ` Steven Rostedt
2013-08-28 13:37 ` Peter Zijlstra
2013-08-29 15:24 ` Waiman Long
2013-08-29 17:03 ` Alexander Fyodorov
2013-08-30 3:16 ` Waiman Long
2013-08-30 8:15 ` Alexander Fyodorov
2013-08-13 18:41 [PATCH RFC v2 0/2] qspinlock: Introducing a 4-byte queue spinlock Waiman Long
2013-08-13 18:41 ` [PATCH RFC v2 1/2] qspinlock: Introducing a 4-byte queue spinlock implementation Waiman Long
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=20130828012128.GT3871@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=aswin@hp.com \
--cc=halcy@yandex.ru \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=scott.norton@hp.com \
--cc=tglx@linutronix.de \
--cc=waiman.long@hp.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