From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753557AbbCQMOY (ORCPT ); Tue, 17 Mar 2015 08:14:24 -0400 Received: from e39.co.us.ibm.com ([32.97.110.160]:57173 "EHLO e39.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752186AbbCQMOX (ORCPT ); Tue, 17 Mar 2015 08:14:23 -0400 Date: Tue, 17 Mar 2015 05:01:10 -0700 From: "Paul E. McKenney" To: Peter Zijlstra Cc: Mathieu Desnoyers , linux-kernel@vger.kernel.org, KOSAKI Motohiro , Steven Rostedt , Nicholas Miell , Linus Torvalds , Ingo Molnar , Alan Cox , Lai Jiangshan , Stephen Hemminger , Andrew Morton , Josh Triplett , Thomas Gleixner , David Howells , Nick Piggin Subject: Re: [RFC PATCH] sys_membarrier(): system/process-wide memory barrier (x86) (v12) Message-ID: <20150317120110.GA10078@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com References: <1426447459-28620-1-git-send-email-mathieu.desnoyers@efficios.com> <20150316141939.GE21418@twins.programming.kicks-ass.net> <1203077851.9491.1426520636551.JavaMail.zimbra@efficios.com> <20150316172104.GH21418@twins.programming.kicks-ass.net> <1003922584.10662.1426532015839.JavaMail.zimbra@efficios.com> <20150316205435.GJ21418@twins.programming.kicks-ass.net> <910572156.13900.1426556725438.JavaMail.zimbra@efficios.com> <20150317063059.GJ2896@worktop.programming.kicks-ass.net> <20150317115608.GF3589@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150317115608.GF3589@linux.vnet.ibm.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15031712-0033-0000-0000-000003F88B01 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 17, 2015 at 04:56:08AM -0700, Paul E. McKenney wrote: > On Tue, Mar 17, 2015 at 07:30:59AM +0100, Peter Zijlstra wrote: > > On Tue, Mar 17, 2015 at 01:45:25AM +0000, Mathieu Desnoyers wrote: > > [ . . . ] > > > > Then we can add > > > the expedited-private implementation after rq->curr becomes > > > available through RCU. > > > > Yeah, or not at all; I'm still trying to get Paul to remove the > > expedited nonsense from the kernel RCU bits; and now you want it in > > userspace too :/ > > Well, the expedited RCU primitives got added for some use cases, and > those use cases are still with us. ;-) And, as I was meaning to say -before- I hit send... I still have some changes in mind to make the expedited RCU primitives at least somewhat more friendly, for example, moving from try_stop_cpus() to something like on_each_cpu_mask(). Thanx, Paul