Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755303AbXHPEMJ (ORCPT ); Thu, 16 Aug 2007 00:12:09 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751275AbXHPELw (ORCPT ); Thu, 16 Aug 2007 00:11:52 -0400 Received: from ozlabs.org ([203.10.76.45]:42424 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751238AbXHPELu (ORCPT ); Thu, 16 Aug 2007 00:11:50 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18115.52863.638655.658466@cargo.ozlabs.ibm.com> Date: Thu, 16 Aug 2007 14:11:43 +1000 From: Paul Mackerras To: Satyam Sharma Cc: Herbert Xu , Christoph Lameter , "Paul E. McKenney" , Stefan Richter , 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 In-Reply-To: References: <20070809131423.GA9927@shell.boston.redhat.com> <46C2D6F3.3070707@s5r6.in-berlin.de> <18115.35524.56393.347841@cargo.ozlabs.ibm.com> <20070816003948.GY9645@linux.vnet.ibm.com> <18115.44462.622801.683446@cargo.ozlabs.ibm.com> <20070816020042.GA30650@gondor.apana.org.au> <18115.45316.702491.681906@cargo.ozlabs.ibm.com> X-Mailer: VM 7.19 under Emacs 21.4.1 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1866 Lines: 41 Satyam Sharma writes: > Anyway, the problem, of course, is that this conversion to a stronger / > safer-by-default behaviour doesn't happen with zero cost to performance. > Converting atomic ops to "volatile" behaviour did add ~2K to kernel text > for archs such as i386 (possibly to important codepaths) that didn't have > those semantics already so it would be constructive to actually look at > those differences and see if there were really any heisenbugs that got > rectified. Or if there were legitimate optimizations that got wrongly > disabled. Onus lies on those proposing the modifications, I'd say ;-) The uses of atomic_read where one might want it to allow caching of the result seem to me to fall into 3 categories: 1. Places that are buggy because of a race arising from the way it's used. 2. Places where there is a race but it doesn't matter because we're doing some clever trick. 3. Places where there is some locking in place that eliminates any potential race. In case 1, adding volatile won't solve the race, of course, but it's hard to argue that we shouldn't do something because it will slow down buggy code. Case 2 is hopefully pretty rare and accompanied by large comment blocks, and in those cases caching the result of atomic_read explicitly in a local variable would probably make the code clearer. And in case 3 there is no reason to use atomic_t at all; we might as well just use an int. So I don't see any good reason to make the atomic API more complex by having "volatile" and "non-volatile" versions of atomic_read. It should just have the "volatile" behaviour. Paul. - 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/