Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754132AbbDVUkl (ORCPT ); Wed, 22 Apr 2015 16:40:41 -0400 Received: from mail.efficios.com ([78.47.125.74]:60634 "EHLO mail.efficios.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751742AbbDVUkj (ORCPT ); Wed, 22 Apr 2015 16:40:39 -0400 Date: Wed, 22 Apr 2015 20:40:42 +0000 (UTC) From: Mathieu Desnoyers To: Pranith Kumar Cc: LKML , Josh Triplett , KOSAKI Motohiro , Steven Rostedt , Nicholas Miell , Linus Torvalds , Ingo Molnar , Alan Cox , Lai Jiangshan , Stephen Hemminger , Andrew Morton , Thomas Gleixner , Peter Zijlstra , David Howells , Michael Kerrisk Message-ID: <1526056761.34535.1429735242508.JavaMail.zimbra@efficios.com> In-Reply-To: References: <1429283202-6245-1-git-send-email-mathieu.desnoyers@efficios.com> Subject: Re: [PATCH v16] sys_membarrier(): system-wide memory barrier (generic, x86) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [192.222.194.238] X-Mailer: Zimbra 8.0.7_GA_6021 (ZimbraWebClient - FF37 (Linux)/8.0.7_GA_6021) Thread-Topic: sys_membarrier(): system-wide memory barrier (generic, x86) Thread-Index: bWB1S3AuHmGsOQ0HJak/CYT3Enbm6A== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2619 Lines: 81 ----- Original Message ----- > On Fri, Apr 17, 2015 at 11:06 AM, Mathieu Desnoyers > wrote: > > diff --git a/init/Kconfig b/init/Kconfig > > index f5dbc6d..89bad6a 100644 > > --- a/init/Kconfig > > +++ b/init/Kconfig > > @@ -1559,6 +1559,19 @@ config PCI_QUIRKS > > bugs/quirks. Disable this only if your target machine is > > unaffected by PCI quirks. > > > > +config MEMBARRIER > > + bool "Enable membarrier() system call" if EXPERT > > + default y > > + depends on SMP > > + help > > + Enable the membarrier() system call that allows issuing memory > > + barriers across all running threads, which can be used to > > distribute > > + the cost of user-space memory barriers asymmetrically by > > transforming > > + pairs of memory barriers into pairs consisting of membarrier() > > and a > > + compiler barrier. > > + > > + If unsure, say Y. > > + > > I understand why this syscall makes sense on SMP only, but you are > anyways checking num_online_cpus() and returning if it is only one. Is > this limitation necessary then? How do !SMP systems handle this > syscall? (I am guessing glibc wrapper?) For !SMP, this system call is not implemented (returns -ENOSYS). Userspace libs are expected to query sysconf(_SC_NPROCESSORS_CONF) and check whether the system supports multiprocessor at all. If only a single processor is supported by the kernel, then userspace can skip the calls to sys_membarrier altogether, because they are not even needed. Do you think this kind of information belongs in a man page ? Should we instead just implement the system call in !SMP, and return 0 without any side-effect ? This would be a bit inefficient to let userspace call a system call that has no effect whatsoever. Thanks, Mathieu > ... > > > +SYSCALL_DEFINE2(membarrier, int, cmd, int, flags) > > +{ > > + switch (cmd) { > > + case MEMBARRIER_CMD_QUERY: > > + return MEMBARRIER_CMD_BITMASK; > > + case MEMBARRIER_CMD_SHARED: > > + if (num_online_cpus() > 1) > > + synchronize_sched(); > > + return 0; > > + default: > > + return -EINVAL; > > + } > > +} > > > > -- > Pranith > -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/