Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759272AbXHQMkU (ORCPT ); Fri, 17 Aug 2007 08:40:20 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756991AbXHQMkA (ORCPT ); Fri, 17 Aug 2007 08:40:00 -0400 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 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAPwzxUbLrQKa/2dsb2JhbAA X-IronPort-AV: i="4.19,275,1183305600"; d="scan'208"; a="183079800:sNHT9122646" Message-ID: <46C59717.4020108@cyberone.com.au> Date: Fri, 17 Aug 2007 22:39:51 +1000 From: Nick Piggin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20051007 Debian/1.7.12-1 X-Accept-Language: en MIME-Version: 1.0 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 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-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2770 Lines: 75 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... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/