From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from webmail.icp-qv1-irony3.iinet.net.au ([203.59.1.108]:13885 "EHLO webmail.icp-qv1-irony3.iinet.net.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752772AbXHQMj6 (ORCPT ); Fri, 17 Aug 2007 08:39:58 -0400 Message-ID: <46C59717.4020108@cyberone.com.au> Date: Fri, 17 Aug 2007 22:39:51 +1000 From: Nick Piggin MIME-Version: 1.0 Subject: Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures References: <18115.52863.638655.658466@cargo.ozlabs.ibm.com> <20070816053945.GB32442@gondor.apana.org.au> <18115.62741.807704.969977@cargo.ozlabs.ibm.com> <20070816070907.GA964@gondor.apana.org.au> <46C4ABA5.9010804@redhat.com> <18117.1287.779351.836552@cargo.ozlabs.ibm.com> <18117.6495.397597.582736@cargo.ozlabs.ibm.com> <20070817035342.GA14744@gondor.apana.org.au> <46C55E90.7010407@yahoo.com.au> <46C56ADF.8010501@cyberone.com.au> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-arch-owner@vger.kernel.org To: Satyam Sharma Cc: Herbert Xu , Paul Mackerras , Linus Torvalds , Christoph Lameter , Chris Snook , Ilpo Jarvinen , "Paul E. McKenney" , Stefan Richter , Linux Kernel Mailing List , linux-arch@vger.kernel.org, Netdev , Andrew Morton , ak@suse.de, heiko.carstens@de.ibm.com, David Miller , schwidefsky@de.ibm.com, wensong@linux-vs.org, horms@verge.net.au, wjiang@resilience.com, cfriesen@nortel.com, zlynx@acm.org, rpjday@mindspring.com, jesper.juhl@gmail.com, segher@kernel.crashing.org List-ID: Satyam Sharma wrote: > >On Fri, 17 Aug 2007, Nick Piggin wrote: > > >>Because they should be thinking about them in terms of barriers, over >>which the compiler / CPU is not to reorder accesses or cache memory >>operations, rather than "special" "volatile" accesses. >> > >This is obviously just a taste thing. Whether to have that forget(x) >barrier as something author should explicitly sprinkle appropriately >in appropriate places in the code by himself or use a primitive that >includes it itself. > That's not obviously just taste to me. Not when the primitive has many (perhaps, the majority) of uses that do not require said barriers. And this is not solely about the code generation (which, as Paul says, is relatively minor even on x86). I prefer people to think explicitly about barriers in their lockless code. >I'm not saying "taste matters aren't important" (they are), but I'm really >skeptical if most folks would find the former tasteful. > So I /do/ have better taste than most folks? Thanks! :-) >>>And by the way, the point is *also* about the fact that cpu_relax(), as >>>of today, implies a full memory clobber, which is not what a lot of such >>>loops want. (due to stuff mentioned elsewhere, summarized in that summary) >>> >>That's not the point, >> > >That's definitely the point, why not. This is why "barrier()", being >heavy-handed, is not the best option. > That is _not_ the point (of why a volatile atomic_read is good) because there has already been an alternative posted that better conforms with Linux barrier API and is much more widely useful and more usable. If you are so worried about barrier() being too heavyweight, then you're off to a poor start by wanting to add a few K of kernel text by making atomic_read volatile. >>because as I also mentioned, the logical extention >>to Linux's barrier API to handle this is the order(x) macro. Again, not >>special volatile accessors. >> > >Sure, that forget(x) macro _is_ proposed to be made part of the generic >API. Doesn't explain why not to define/use primitives that has volatility >semantics in itself, though (taste matters apart). > If you follow the discussion.... You were thinking of a reason why the semantics *should* be changed or added, and I was rebutting your argument that it must be used when a full barrier() is too heavy (ie. by pointing out that order() has superior semantics anyway). Why do I keep repeating the same things? I'll not continue bloating this thread until a new valid point comes up...