From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754111AbbCPNAf (ORCPT ); Mon, 16 Mar 2015 09:00:35 -0400 Received: from mail.efficios.com ([78.47.125.74]:46328 "EHLO mail.efficios.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750948AbbCPNAc (ORCPT ); Mon, 16 Mar 2015 09:00:32 -0400 Date: Mon, 16 Mar 2015 13:00:24 +0000 (UTC) From: Mathieu Desnoyers To: Josh Triplett Cc: linux-kernel@vger.kernel.org, KOSAKI Motohiro , Steven Rostedt , "Paul E. McKenney" , Nicholas Miell , Linus Torvalds , Ingo Molnar , Alan Cox , Lai Jiangshan , Stephen Hemminger , Andrew Morton , Thomas Gleixner , Peter Zijlstra , David Howells , Nick Piggin Message-ID: <1181775493.9326.1426510824610.JavaMail.zimbra@efficios.com> In-Reply-To: <20150316032550.GA1110@thin> References: <1426447459-28620-1-git-send-email-mathieu.desnoyers@efficios.com> <20150316032550.GA1110@thin> Subject: Re: [RFC PATCH] sys_membarrier(): system/process-wide memory barrier (x86) (v12) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [192.222.176.50] X-Mailer: Zimbra 8.0.7_GA_6021 (ZimbraWebClient - FF36 (Linux)/8.0.7_GA_6021) Thread-Topic: sys_membarrier(): system/process-wide memory barrier (x86) (v12) Thread-Index: +PV37UU3lcuCXXq/KWDe8le3QmzaOg== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org ----- Original Message ----- > From: "Josh Triplett" > To: "Mathieu Desnoyers" > Cc: linux-kernel@vger.kernel.org, "KOSAKI Motohiro" , "Steven Rostedt" > , "Paul E. McKenney" , "Nicholas Miell" , > "Linus Torvalds" , "Ingo Molnar" , "Alan Cox" > , "Lai Jiangshan" , "Stephen Hemminger" > , "Andrew Morton" , "Thomas Gleixner" , > "Peter Zijlstra" , "David Howells" , "Nick Piggin" > Sent: Sunday, March 15, 2015 11:25:50 PM > Subject: Re: [RFC PATCH] sys_membarrier(): system/process-wide memory barrier (x86) (v12) > > On Sun, Mar 15, 2015 at 03:24:19PM -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_FLAG) or calls synchronize_sched() to issue > > a memory barrier on all threads running on the system. It can be used to > > distribute the cost of user-space memory barriers asymmetrically by > > transforming pairs of memory barriers into pairs consisting of > > sys_membarrier() and a compiler barrier. For synchronization primitives > > that distinguish between read-side and write-side (e.g. userspace RCU, > > rwlocks), the read-side can be accelerated significantly by moving the > > bulk of the memory barrier overhead to the write-side. > > From a quick review, this seems quite reasonable (as it did 5 years > ago). > > One request: Could you please add a config option (default y) in the > EXPERT menu to disable this? You actually seem to already have it > marked as a cond_syscall. Sure, done. > > Also, a very minor nit: flags in kernel APIs aren't typically named with > a _FLAG suffix. OK, good point. > > With the syscall made optional, and with or without that naming nit > fixed: > Reviewed-by: Josh Triplett Thanks! Mathieu > > - Josh Triplett > -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com