From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754584AbbCQXgq (ORCPT ); Tue, 17 Mar 2015 19:36:46 -0400 Received: from relay3-d.mail.gandi.net ([217.70.183.195]:52568 "EHLO relay3-d.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753933AbbCQXgn (ORCPT ); Tue, 17 Mar 2015 19:36:43 -0400 X-Originating-IP: 50.43.43.179 Date: Tue, 17 Mar 2015 16:36:30 -0700 From: Josh Triplett To: Mathieu Desnoyers Cc: Peter Zijlstra , linux-kernel@vger.kernel.org, "Paul E. McKenney" , KOSAKI Motohiro , Steven Rostedt , Nicholas Miell , Linus Torvalds , Ingo Molnar , Alan Cox , Lai Jiangshan , Stephen Hemminger , Andrew Morton , Thomas Gleixner , David Howells Subject: Re: [RFC PATCH v13] sys_membarrier(): system/process-wide memory barrier (x86) Message-ID: <20150317233629.GA8578@thin> References: <1426612922-3308-1-git-send-email-mathieu.desnoyers@efficios.com> <20150317173035.GI23123@twins.programming.kicks-ass.net> <20150317175750.GB4141@cloud> <20150317180824.GK23123@twins.programming.kicks-ass.net> <1338809369.22714.1426618883816.JavaMail.zimbra@efficios.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1338809369.22714.1426618883816.JavaMail.zimbra@efficios.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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