Re: [RFC PATCH v13] sys_membarrier(): system/process-wide memory barrier (x86)
From: Josh Triplett
Date: Tue Mar 17 2015 - 19:36:54 EST
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@xxxxxxxxxxxxxxxx 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/