From: Josh Triplett <josh@joshtriplett.org>
To: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
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 16:36:30 -0700 [thread overview]
Message-ID: <20150317233629.GA8578@thin> (raw)
In-Reply-To: <1338809369.22714.1426618883816.JavaMail.zimbra@efficios.com>
On Tue, Mar 17, 2015 at 07:01:23PM +0000, Mathieu Desnoyers wrote:
> ----- Original Message -----
> > On Tue, Mar 17, 2015 at 10:57:50AM -0700, josh@joshtriplett.org wrote:
> > > 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.
> >
> > Sure; but why bother with pointless fluff like that? We can always
> > introduce the private flag if and when it starts to make sense having
> > it.
>
> Without the expedited implementation, the only usefulness of the
> private flag is to skip synchronize_sched() if called from a
> single-threaded process.
>
> We could easily argue that if a process is using sys_membarrier in
> the first place, it's very likely that it is multithreaded. So I
> agree that we can drop the flag for now, and add it later on,
> e.g. when adding the expedited mode.
>
> I am tempted to leave the "flags" argument in place though, along
> with the "MEMBARRIER_QUERY" flag. Thoughts ?
You should definitely *always* supply a flags argument with any new
syscall, even if you have no flags yet.
As for QUERY, I assume that exists because the more expensive forms of
barriers (e.g. expedited) are sufficiently invasive that you don't want
to trigger one when not needed just to test if they work? If so, then
yeah, having that flag seems fine.
- Josh Triplett
next prev parent reply other threads:[~2015-03-17 23:36 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
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 [this message]
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=20150317233629.GA8578@thin \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox