Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1763908AbXHPGAb (ORCPT ); Thu, 16 Aug 2007 02:00:31 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752064AbXHPGAR (ORCPT ); Thu, 16 Aug 2007 02:00:17 -0400 Received: from ozlabs.org ([203.10.76.45]:35633 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754516AbXHPGAP (ORCPT ); Thu, 16 Aug 2007 02:00:15 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18115.59365.268987.406001@cargo.ozlabs.ibm.com> Date: Thu, 16 Aug 2007 16:00:05 +1000 From: Paul Mackerras To: Herbert Xu Cc: Christoph Lameter , Satyam Sharma , "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: <20070816053741.GA32442@gondor.apana.org.au> References: <20070816011414.GC9645@linux.vnet.ibm.com> <20070816020851.GA30809@gondor.apana.org.au> <18115.49946.522011.832468@cargo.ozlabs.ibm.com> <20070816033343.GA31844@gondor.apana.org.au> <18115.51472.408193.332905@cargo.ozlabs.ibm.com> <20070816040308.GA32133@gondor.apana.org.au> <18115.54225.644905.463771@cargo.ozlabs.ibm.com> <20070816053741.GA32442@gondor.apana.org.au> 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: 1317 Lines: 31 Herbert Xu writes: > It doesn't matter. The memory pressure flag is an *advisory* > flag. If we get it wrong the worst that'll happen is that we'd > waste some time doing work that'll be thrown away. Ah, so it's the "racy but I don't care because it's only an optimization" case. That's fine. Somehow I find it hard to believe that all the racy uses of atomic_read in the kernel are like that, though. :) > In any case, this actually illustrates why the addition of > volatile is completely pointless. Even if this code was > broken, which it definitely is not, having the volatile > there wouldn't have helped at all. Yes, adding volatile to racy code doesn't somehow make it race-free. Neither does using atomic_t, despite what some seem to believe. I have actually started going through all the uses of atomic_read in the kernel. So far out of the first 100 I have found none where we have two atomic_reads of the same variable and the compiler could usefully use the value from the first as the result of the second. But there's still > 2500 to go... 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/