From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752524AbbCPD0G (ORCPT ); Sun, 15 Mar 2015 23:26:06 -0400 Received: from relay6-d.mail.gandi.net ([217.70.183.198]:43128 "EHLO relay6-d.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750937AbbCPD0D (ORCPT ); Sun, 15 Mar 2015 23:26:03 -0400 X-Originating-IP: 50.43.43.179 Date: Sun, 15 Mar 2015 20:25:50 -0700 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 Subject: Re: [RFC PATCH] sys_membarrier(): system/process-wide memory barrier (x86) (v12) Message-ID: <20150316032550.GA1110@thin> References: <1426447459-28620-1-git-send-email-mathieu.desnoyers@efficios.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1426447459-28620-1-git-send-email-mathieu.desnoyers@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 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. Also, a very minor nit: flags in kernel APIs aren't typically named with a _FLAG suffix. With the syscall made optional, and with or without that naming nit fixed: Reviewed-by: Josh Triplett - Josh Triplett