Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759694AbXHTNf3 (ORCPT ); Mon, 20 Aug 2007 09:35:29 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1757161AbXHTNfO (ORCPT ); Mon, 20 Aug 2007 09:35:14 -0400 Received: from rhun.apana.org.au ([64.62.148.172]:3865 "EHLO arnor.apana.org.au" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1756416AbXHTNfL (ORCPT ); Mon, 20 Aug 2007 09:35:11 -0400 Date: Mon, 20 Aug 2007 21:32:07 +0800 From: Herbert Xu To: Chris Snook Cc: Linus Torvalds , Nick Piggin , Satyam Sharma , Paul Mackerras , Christoph Lameter , 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 Message-ID: <20070820133207.GA13835@gondor.apana.org.au> References: <18117.6495.397597.582736@cargo.ozlabs.ibm.com> <20070817035342.GA14744@gondor.apana.org.au> <46C55E90.7010407@yahoo.com.au> <46C56ADF.8010501@cyberone.com.au> <46C59717.4020108@cyberone.com.au> <46C993DF.4080400@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46C993DF.4080400@redhat.com> User-Agent: Mutt/1.5.9i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1404 Lines: 37 On Mon, Aug 20, 2007 at 09:15:11AM -0400, Chris Snook wrote: > Linus Torvalds wrote: > >So the only reason to add back "volatile" to the atomic_read() sequence is > >not to fix bugs, but to _hide_ the bugs better. They're still there, they > >are just a lot harder to trigger, and tend to be a lot subtler. > > What about barrier removal? With consistent semantics we could optimize a > fair amount of code. Whether or not that constitutes "premature" > optimization is open to debate, but there's no question we could reduce our > register wiping in some places. If you've been reading all of Linus's emails you should be thinking about adding memory barriers, and not removing compiler barriers. He's just told you that code of the kind while (!atomic_read(cond)) ; do_something() probably needs a memory barrier (not just compiler) so that do_something() doesn't see stale cache content that occured before cond flipped. 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/