Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932487AbXHPKnp (ORCPT ); Thu, 16 Aug 2007 06:43:45 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1757715AbXHPKne (ORCPT ); Thu, 16 Aug 2007 06:43:34 -0400 Received: from rhun.apana.org.au ([64.62.148.172]:2754 "EHLO arnor.apana.org.au" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1757452AbXHPKnc (ORCPT ); Thu, 16 Aug 2007 06:43:32 -0400 Date: Thu, 16 Aug 2007 18:42:50 +0800 From: Herbert Xu To: Stefan Richter Cc: Paul Mackerras , Satyam Sharma , Christoph Lameter , "Paul E. McKenney" , Chris Snook , Linux Kernel Mailing List , linux-arch@vger.kernel.org, Linus Torvalds , netdev@vger.kernel.org, Andrew Morton , ak@suse.de, heiko.carstens@de.ibm.com, davem@davemloft.net, 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 Message-ID: <20070816104250.GB2927@gondor.apana.org.au> 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> <46C40587.7050708@s5r6.in-berlin.de> <20070816081049.GA1431@gondor.apana.org.au> <46C41EE4.9090806@s5r6.in-berlin.de> <46C42767.4070104@s5r6.in-berlin.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46C42767.4070104@s5r6.in-berlin.de> User-Agent: Mutt/1.5.9i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1874 Lines: 47 On Thu, Aug 16, 2007 at 12:31:03PM +0200, Stefan Richter wrote: > > PS: Just to clarify, I'm not speaking for the volatile modifier. I'm > not speaking for any particular implementation of atomic_t and its > accessors at all. All I am saying is that > - we use atomically accessed data types because we concurrently but > locklessly access this data, > - hence a read access to this data that could be optimized away > makes *no sense at all*. No sane compiler can optimise away an atomic_read per se. That's only possible if there's a preceding atomic_set or atomic_read, with no barriers in the middle. If that's the case, then one has to conclude that doing away with the second read is acceptable, as otherwise a memory (or at least a compiler) barrier should have been used. In fact, volatile doesn't guarantee that the memory gets read anyway. You might be reading some stale value out of the cache. Granted this doesn't happen on x86 but when you're coding for the kernel you can't make such assumptions. So the point here is that if you don't mind getting a stale value from the CPU cache when doing an atomic_read, then surely you won't mind getting a stale value from the compiler "cache". > So, the architecture guys can implement atomic_read however they want > --- as long as it cannot be optimized away.* They can implement it however they want as long as it stays atomic. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt - 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/