From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754906Ab3KEOt7 (ORCPT ); Tue, 5 Nov 2013 09:49:59 -0500 Received: from e7.ny.us.ibm.com ([32.97.182.137]:58828 "EHLO e7.ny.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754481Ab3KEOt5 (ORCPT ); Tue, 5 Nov 2013 09:49:57 -0500 Date: Tue, 5 Nov 2013 06:49:00 -0800 From: "Paul E. McKenney" To: Will Deacon Cc: Peter Zijlstra , Linus Torvalds , Victor Kaplansky , Oleg Nesterov , Anton Blanchard , Benjamin Herrenschmidt , Frederic Weisbecker , LKML , Linux PPC dev , Mathieu Desnoyers , Michael Ellerman , Michael Neuling , "linux@arm.linux.org.uk" , "schwidefsky@de.ibm.com" , "heiko.carstens@de.ibm.com" Subject: Re: [RFC] arch: Introduce new TSO memory barrier smp_tmb() Message-ID: <20131105144900.GD3947@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com References: <20131103200124.GK19466@laptop.lan> <20131103224242.GF3947@linux.vnet.ibm.com> <20131104105059.GL3947@linux.vnet.ibm.com> <20131104112254.GK28601@twins.programming.kicks-ass.net> <20131104162732.GN3947@linux.vnet.ibm.com> <20131104191127.GW16117@laptop.programming.kicks-ass.net> <20131104205344.GW3947@linux.vnet.ibm.com> <20131105140548.GD26895@mudshark.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131105140548.GD26895@mudshark.cambridge.arm.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-MML: No X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13110514-5806-0000-0000-00002351FC55 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Nov 05, 2013 at 02:05:48PM +0000, Will Deacon wrote: > On Mon, Nov 04, 2013 at 08:53:44PM +0000, Paul E. McKenney wrote: > > On Mon, Nov 04, 2013 at 08:11:27PM +0100, Peter Zijlstra wrote: > > Some comments below. I believe that opcodes need to be fixed for IA64. > > I am unsure of the ifdefs and opcodes for arm64, but the ARM folks should > > be able to tell us. [ . . . ] > > > +} while (0) > > > + > > > +#define smp_load_acquire(p) \ > > > +do { \ > > > + typeof(p) ___p1; \ > > > + asm volatile ("ldar %w0, [%1]" \ > > > + : "=r" (___p1) : "r" (&p) : "memory"); \ > > > + return ___p1; \ > > Similar comments here wrt Q constraint. > > Random other question: have you considered how these accessors should behave > when presented with __iomem pointers? Should we have something to make sparse yell if not __kernel or some such? Thanx, Paul From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.151]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "e33.co.us.ibm.com", Issuer "GeoTrust SSL CA" (not verified)) by ozlabs.org (Postfix) with ESMTPS id D5B852C020A for ; Wed, 6 Nov 2013 01:49:41 +1100 (EST) Received: from /spool/local by e33.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 5 Nov 2013 07:49:36 -0700 Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by d03dlp03.boulder.ibm.com (Postfix) with ESMTP id 126D119D8036 for ; Tue, 5 Nov 2013 07:49:29 -0700 (MST) Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id rA5EnQ14064550 for ; Tue, 5 Nov 2013 07:49:28 -0700 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 rA5EppYB029243 for ; Tue, 5 Nov 2013 07:51:53 -0700 Date: Tue, 5 Nov 2013 06:49:00 -0800 From: "Paul E. McKenney" To: Will Deacon Subject: Re: [RFC] arch: Introduce new TSO memory barrier smp_tmb() Message-ID: <20131105144900.GD3947@linux.vnet.ibm.com> References: <20131103200124.GK19466@laptop.lan> <20131103224242.GF3947@linux.vnet.ibm.com> <20131104105059.GL3947@linux.vnet.ibm.com> <20131104112254.GK28601@twins.programming.kicks-ass.net> <20131104162732.GN3947@linux.vnet.ibm.com> <20131104191127.GW16117@laptop.programming.kicks-ass.net> <20131104205344.GW3947@linux.vnet.ibm.com> <20131105140548.GD26895@mudshark.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <20131105140548.GD26895@mudshark.cambridge.arm.com> Cc: Michael Neuling , Mathieu Desnoyers , Peter Zijlstra , "heiko.carstens@de.ibm.com" , Oleg Nesterov , LKML , Linux PPC dev , Anton Blanchard , Frederic Weisbecker , Victor Kaplansky , "linux@arm.linux.org.uk" , Linus Torvalds , "schwidefsky@de.ibm.com" 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 Tue, Nov 05, 2013 at 02:05:48PM +0000, Will Deacon wrote: > On Mon, Nov 04, 2013 at 08:53:44PM +0000, Paul E. McKenney wrote: > > On Mon, Nov 04, 2013 at 08:11:27PM +0100, Peter Zijlstra wrote: > > Some comments below. I believe that opcodes need to be fixed for IA64. > > I am unsure of the ifdefs and opcodes for arm64, but the ARM folks should > > be able to tell us. [ . . . ] > > > +} while (0) > > > + > > > +#define smp_load_acquire(p) \ > > > +do { \ > > > + typeof(p) ___p1; \ > > > + asm volatile ("ldar %w0, [%1]" \ > > > + : "=r" (___p1) : "r" (&p) : "memory"); \ > > > + return ___p1; \ > > Similar comments here wrt Q constraint. > > Random other question: have you considered how these accessors should behave > when presented with __iomem pointers? Should we have something to make sparse yell if not __kernel or some such? Thanx, Paul