From: josh@joshtriplett.org
To: Peter Zijlstra <peterz@infradead.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
linux-kernel@vger.kernel.org,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Steven Rostedt <rostedt@goodmis.org>,
Nicholas Miell <nmiell@comcast.net>,
Linus Torvalds <torvalds@linux-foundation.org>,
Ingo Molnar <mingo@redhat.com>,
Alan Cox <gnomes@lxorguk.ukuu.org.uk>,
Lai Jiangshan <laijs@cn.fujitsu.com>,
Stephen Hemminger <stephen@networkplumber.org>,
Andrew Morton <akpm@linux-foundation.org>,
Thomas Gleixner <tglx@linutronix.de>,
David Howells <dhowells@redhat.com>
Subject: Re: [RFC PATCH v13] sys_membarrier(): system/process-wide memory barrier (x86)
Date: Tue, 17 Mar 2015 10:57:50 -0700 [thread overview]
Message-ID: <20150317175750.GB4141@cloud> (raw)
In-Reply-To: <20150317173035.GI23123@twins.programming.kicks-ass.net>
On Tue, Mar 17, 2015 at 06:30:35PM +0100, Peter Zijlstra wrote:
> On Tue, Mar 17, 2015 at 01:22:02PM -0400, Mathieu Desnoyers wrote:
> > Here is an implementation of a new system call, sys_membarrier(), which
> > executes a memory barrier on either all running threads of the current
> > process (MEMBARRIER_PRIVATE) issues a memory barrier on all threads
> > running on the system (~MEMBARRIER_PRIVATE). Both are currently
> > implemented by calling synchronize_sched().
>
> Then why bother with the flag?
Semantically, MEMBARRIER_PRIVATE is allowed to avoid issuing a barrier
on CPUs not running the current process if it can, while
~MEMBARRIER_PRIVATE may not. (The latter would be useful for
applications such as system-wide tracing.) That they're currently both
implemented the same way doesn't mean they're semantically equivalent.
- Josh Triplett
next prev parent reply other threads:[~2015-03-17 17:57 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-17 17:22 [RFC PATCH v13] sys_membarrier(): system/process-wide memory barrier (x86) Mathieu Desnoyers
2015-03-17 17:30 ` Peter Zijlstra
2015-03-17 17:57 ` josh [this message]
2015-03-17 18:08 ` Peter Zijlstra
2015-03-17 19:01 ` Mathieu Desnoyers
2015-03-17 20:28 ` Olaf Titz
2015-03-17 23:36 ` Josh Triplett
2015-03-17 18:00 ` josh
2015-03-17 18:54 ` Mathieu Desnoyers
2015-03-17 19:27 ` Mathieu Desnoyers
2015-03-18 14:41 ` Paul E. McKenney
2015-03-18 16:22 ` Mathieu Desnoyers
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=20150317175750.GB4141@cloud \
--to=josh@joshtriplett.org \
--cc=akpm@linux-foundation.org \
--cc=dhowells@redhat.com \
--cc=gnomes@lxorguk.ukuu.org.uk \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=laijs@cn.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mingo@redhat.com \
--cc=nmiell@comcast.net \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=stephen@networkplumber.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.