From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760790AbcBYPmI (ORCPT ); Thu, 25 Feb 2016 10:42:08 -0500 Received: from e37.co.us.ibm.com ([32.97.110.158]:40144 "EHLO e37.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1760202AbcBYPmF (ORCPT ); Thu, 25 Feb 2016 10:42:05 -0500 X-IBM-Helo: d03dlp03.boulder.ibm.com X-IBM-MailFrom: paulmck@linux.vnet.ibm.com X-IBM-RcptTo: linux-kernel@vger.kernel.org Date: Thu, 25 Feb 2016 07:42:01 -0800 From: "Paul E. McKenney" To: Peter Zijlstra Cc: Mathieu Desnoyers , linux-kernel@vger.kernel.org, Ingo Molnar , Lai Jiangshan , dipankar@in.ibm.com, Andrew Morton , josh@joshtriplett.org, Thomas Gleixner , rostedt , David Howells , edumazet@google.com, dvhart@linux.intel.com, fweisbec@gmail.com, Oleg Nesterov , bobby prani Subject: Re: [PATCH tip/core/rcu 02/14] documentation: Fix control dependency and identical stores Message-ID: <20160225154201.GN3522@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com References: <20160224050021.GA14616@linux.vnet.ibm.com> <1456290047-16654-2-git-send-email-paulmck@linux.vnet.ibm.com> <467632883.7240.1456348324456.JavaMail.zimbra@efficios.com> <20160224214013.GF3522@linux.vnet.ibm.com> <20160225082143.GZ6357@twins.programming.kicks-ass.net> <20160225140703.GJ3522@linux.vnet.ibm.com> <20160225144838.GP6356@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160225144838.GP6356@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: 16022515-0025-0000-0000-000021B67AEA Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Feb 25, 2016 at 03:48:38PM +0100, Peter Zijlstra wrote: > On Thu, Feb 25, 2016 at 06:07:03AM -0800, Paul E. McKenney wrote: > > Still bad wording... > > > > It hasn't actually moved anything over the barrier(). It has instead > > moved both the barrier() and the WRITE_ONCE(b, p) to precede the "if > > (q)". Mathieu mentioned this over IRC yesterday, and I queue a change > > so that the paragraph now reads as follows: > > > > (*) If both legs of the "if" statement begin with identical stores to > > the same variable, then those stores must be ordered, either by > > preceding both of them with smp_mb() or by using smp_store_release() > > to carry out the stores. Please note that it is -not- sufficient > > to use barrier() at beginning of each leg of the "if" statement > > because, as shown by the example above, optimizing compilers can > > destroy the control dependency while respecting the letter of the > > barrier() law. > > > > Does hat help? > > Maybe.. I still feel the compiler should not do this; but I'm having a > hard time explaining why. The compiler guys would probably argue that the variable "q" is in a register, so that the "memory" constraint does not apply. Then the code movement does not move any actual memory accesses across the "memory" constraint, and hence they would argue them to be perfectly legal. That said, I completely agree that this sort of code movement is at the very least rather unfriendly to concurrent code. :-/ Thanx, Paul