From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752509AbbLJUll (ORCPT ); Thu, 10 Dec 2015 15:41:41 -0500 Received: from e31.co.us.ibm.com ([32.97.110.149]:39109 "EHLO e31.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751032AbbLJUlk (ORCPT ); Thu, 10 Dec 2015 15:41:40 -0500 X-IBM-Helo: d03dlp02.boulder.ibm.com X-IBM-MailFrom: paulmck@linux.vnet.ibm.com X-IBM-RcptTo: linux-kernel@vger.kernel.org Date: Thu, 10 Dec 2015 12:41:21 -0800 From: "Paul E. McKenney" To: Peter Zijlstra Cc: linux-kernel@vger.kernel.org, mingo@kernel.org, jiangshanlai@gmail.com, dipankar@in.ibm.com, akpm@linux-foundation.org, mathieu.desnoyers@efficios.com, josh@joshtriplett.org, tglx@linutronix.de, rostedt@goodmis.org, dhowells@redhat.com, edumazet@google.com, dvhart@linux.intel.com, fweisbec@gmail.com, oleg@redhat.com, bobby.prani@gmail.com Subject: Re: [PATCH v2 tip/core/rcu 03/11] rcu: Move smp_mb() from rcu_seq_snap() to rcu_exp_gp_seq_snap() Message-ID: <20151210204121.GK28602@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com References: <20151209230243.GA32518@linux.vnet.ibm.com> <1449702188-493-3-git-send-email-paulmck@linux.vnet.ibm.com> <20151210202939.GC6356@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151210202939.GC6356@twins.programming.kicks-ass.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15121020-8236-0000-0000-0000143FE284 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Dec 10, 2015 at 09:29:39PM +0100, Peter Zijlstra wrote: > On Wed, Dec 09, 2015 at 03:03:00PM -0800, Paul E. McKenney wrote: > > The memory barrier in rcu_seq_snap() is needed only for grace periods, > > so this commit moves it to the grace-period-oriented wrapper > > rcu_exp_gp_seq_snap(). > > This is a bit short for a memory barrier changelog. I think I remember > enough of the code to see this is indeed so, but who knows who will > remember what in another few weeks :-) ;-) Would it help to add something like the following? This change does not add or remove a memory barrier, but instead associates it with the right level of abstraction. Thanx, Paul