From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754614Ab0EUF1x (ORCPT ); Fri, 21 May 2010 01:27:53 -0400 Received: from cantor.suse.de ([195.135.220.2]:60672 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752292Ab0EUF1v (ORCPT ); Fri, 21 May 2010 01:27:51 -0400 Date: Fri, 21 May 2010 15:27:46 +1000 From: Nick Piggin To: "Paul E. McKenney" Cc: David Miller , torvalds@linux-foundation.org, anton@samba.org, akpm@linux-foundation.org, willy@linux.intel.com, benh@kernel.crashing.org, paulus@samba.org, linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/2]: atomic_t: Remove volatile from atomic_t definition Message-ID: <20100521052746.GL2516@laptop> References: <20100519130327.GW2516@laptop> <20100519150132.GJ2237@linux.vnet.ibm.com> <20100519.125449.56392211.davem@davemloft.net> <20100519225046.GO2237@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100519225046.GO2237@linux.vnet.ibm.com> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 19, 2010 at 03:50:46PM -0700, Paul E. McKenney wrote: > On Wed, May 19, 2010 at 12:54:49PM -0700, David Miller wrote: > > From: "Paul E. McKenney" > > Date: Wed, 19 May 2010 08:01:32 -0700 > > > > > On Wed, May 19, 2010 at 11:03:27PM +1000, Nick Piggin wrote: > > >> For atomic_read it shouldn't matter unless gcc is *really* bad at it. > > >> Ah, for atomic_read, the required semantic is surely ACCESS_ONCE, so > > >> that's where the volatile is needed? (maybe it would be clearer to > > >> explicitly use ACCESS_ONCE?) > > > > > > Explicit use of ACCESS_ONCE() where needed makes a lot of sense to me, > > > and allows better code to be generated for initialization and cleanup > > > code where no other task has access to the atomic_t. > > > > I agree and I want to see this too, but I think with the tree the size > > that it is we have to work backwards at this point. > > > > Existing behavior by default, and optimized cases get tagged by using > > a new interface (atomic_read_light(), test_bit{,s}_light(), etc.) > > Fair enough! Hmm, I'm missing something. David, back up a second, as far as I can see, with Anton's patches, atomic_read() *is* effectively just ACCESS_ONCE() now. Linus pointed out that header tangle is the reason not to just use the macro. Am I wrong, or is it that ACCESS_ONCE has a more relaxed semantic *in theory* that allows a future more aggressive implementation if the compiler supports it? do { done = ACCESS_ONCE(blah); } while (!done); Is this (in theory) allowed to be turned into a branch into an infinite loop? Wheras the volatile deref would require it be reloaded each time?