From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752233Ab3KCEEn (ORCPT ); Sun, 3 Nov 2013 00:04:43 -0400 Received: from e32.co.us.ibm.com ([32.97.110.150]:44864 "EHLO e32.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750792Ab3KCEEi (ORCPT ); Sun, 3 Nov 2013 00:04:38 -0400 Date: Sat, 2 Nov 2013 10:49:23 -0700 From: "Paul E. McKenney" To: Peter Zijlstra Cc: Victor Kaplansky , Oleg Nesterov , Anton Blanchard , Benjamin Herrenschmidt , Frederic Weisbecker , LKML , Linux PPC dev , Mathieu Desnoyers , Michael Ellerman , Michael Neuling , tony.luck@intel.com Subject: Re: perf events ring buffer memory barrier on powerpc Message-ID: <20131102174922.GD3947@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com References: <20131028132634.GO19466@laptop.lan> <20131028163418.GD4126@linux.vnet.ibm.com> <20131028201735.GA15629@redhat.com> <20131030092725.GL4126@linux.vnet.ibm.com> <20131030112526.GI16117@laptop.programming.kicks-ass.net> <20131031064015.GV4126@linux.vnet.ibm.com> <20131101161819.GV16117@laptop.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131101161819.GV16117@laptop.programming.kicks-ass.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-MML: No X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13110304-0928-0000-0000-00000333DB7E Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Nov 01, 2013 at 05:18:19PM +0100, Peter Zijlstra wrote: > On Wed, Oct 30, 2013 at 11:40:15PM -0700, Paul E. McKenney wrote: > > The dependency you are talking about is via the "if" statement? > > Even C/C++11 is not required to respect control dependencies. > > > > This one is a bit annoying. The x86 TSO means that you really only > > need barrier(), ARM (recent ARM, anyway) and Power could use a weaker > > barrier, and so on -- but smp_mb() emits a full barrier. > > > > Perhaps a new smp_tmb() for TSO semantics, where reads are ordered > > before reads, writes before writes, and reads before writes, but not > > writes before reads? Another approach would be to define a per-arch > > barrier for this particular case. > > Supposing a sane language where we can rely on control flow; would that > change the story? > > I'm afraid I'm now terminally confused between actual proper memory > model issues and fucked compilers. Power and ARM won't speculate stores, but they will happily speculate loads. Not sure about Itanium, perhaps Tony knows. And yes, reordering by the compilers and CPUs does sometimes seem a bit intertwined. Thanx, Paul From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from e36.co.us.ibm.com (e36.co.us.ibm.com [32.97.110.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "e36.co.us.ibm.com", Issuer "GeoTrust SSL CA" (not verified)) by ozlabs.org (Postfix) with ESMTPS id D9D702C0185 for ; Sun, 3 Nov 2013 15:04:40 +1100 (EST) Received: from /spool/local by e36.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Sat, 2 Nov 2013 22:04:38 -0600 Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by d03dlp03.boulder.ibm.com (Postfix) with ESMTP id E201819D8042 for ; Sat, 2 Nov 2013 22:04:30 -0600 (MDT) Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d03relay05.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id rA344Ylb414650 for ; Sat, 2 Nov 2013 22:04:34 -0600 Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id rA347Oxs001985 for ; Sat, 2 Nov 2013 22:07:25 -0600 Date: Sat, 2 Nov 2013 10:49:23 -0700 From: "Paul E. McKenney" To: Peter Zijlstra Subject: Re: perf events ring buffer memory barrier on powerpc Message-ID: <20131102174922.GD3947@linux.vnet.ibm.com> References: <20131028132634.GO19466@laptop.lan> <20131028163418.GD4126@linux.vnet.ibm.com> <20131028201735.GA15629@redhat.com> <20131030092725.GL4126@linux.vnet.ibm.com> <20131030112526.GI16117@laptop.programming.kicks-ass.net> <20131031064015.GV4126@linux.vnet.ibm.com> <20131101161819.GV16117@laptop.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <20131101161819.GV16117@laptop.programming.kicks-ass.net> Cc: Michael Neuling , tony.luck@intel.com, Mathieu Desnoyers , Oleg Nesterov , LKML , Linux PPC dev , Anton Blanchard , Frederic Weisbecker , Victor Kaplansky Reply-To: paulmck@linux.vnet.ibm.com List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Fri, Nov 01, 2013 at 05:18:19PM +0100, Peter Zijlstra wrote: > On Wed, Oct 30, 2013 at 11:40:15PM -0700, Paul E. McKenney wrote: > > The dependency you are talking about is via the "if" statement? > > Even C/C++11 is not required to respect control dependencies. > > > > This one is a bit annoying. The x86 TSO means that you really only > > need barrier(), ARM (recent ARM, anyway) and Power could use a weaker > > barrier, and so on -- but smp_mb() emits a full barrier. > > > > Perhaps a new smp_tmb() for TSO semantics, where reads are ordered > > before reads, writes before writes, and reads before writes, but not > > writes before reads? Another approach would be to define a per-arch > > barrier for this particular case. > > Supposing a sane language where we can rely on control flow; would that > change the story? > > I'm afraid I'm now terminally confused between actual proper memory > model issues and fucked compilers. Power and ARM won't speculate stores, but they will happily speculate loads. Not sure about Itanium, perhaps Tony knows. And yes, reordering by the compilers and CPUs does sometimes seem a bit intertwined. Thanx, Paul