Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1762795AbXHQMxg (ORCPT ); Fri, 17 Aug 2007 08:53:36 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754796AbXHQMxY (ORCPT ); Fri, 17 Aug 2007 08:53:24 -0400 Received: from pentafluge.infradead.org ([213.146.154.40]:53814 "EHLO pentafluge.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752775AbXHQMxW (ORCPT ); Fri, 17 Aug 2007 08:53:22 -0400 Date: Fri, 17 Aug 2007 18:35:54 +0530 (IST) From: Satyam Sharma X-X-Sender: satyam@enigma.security.iitk.ac.in To: Nick Piggin cc: Linus Torvalds , Paul Mackerras , Segher Boessenkool , heiko.carstens@de.ibm.com, horms@verge.net.au, Linux Kernel Mailing List , rpjday@mindspring.com, ak@suse.de, netdev@vger.kernel.org, cfriesen@nortel.com, Andrew Morton , jesper.juhl@gmail.com, linux-arch@vger.kernel.org, zlynx@acm.org, clameter@sgi.com, schwidefsky@de.ibm.com, Chris Snook , Herbert Xu , davem@davemloft.net, wensong@linux-vs.org, wjiang@resilience.com Subject: Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures In-Reply-To: <46C5910A.6020904@cyberone.com.au> Message-ID: References: <46C32618.2080108@redhat.com> <20070815234021.GA28775@gondor.apana.org.au> <3694fb2e4ed1e4d9bf873c0d050c911e@kernel.crashing.org> <46C3B50E.7010702@yahoo.com.au> <194369f4c96ea0e24decf8f9197d5bad@kernel.crashing.org> <46C505B2.6030704@yahoo.com.au> <18117.4848.695269.72976@cargo.ozlabs.ibm.com> <46C54D94.5080803@yahoo.com.au> <46C56725.6000207@cyberone.com.au> <46C5910A.6020904@cyberone.com.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2183 Lines: 74 On Fri, 17 Aug 2007, Nick Piggin wrote: > Satyam Sharma wrote: > [...] > > You think both these are equivalent in terms of "looks": > > > > | > > while (!atomic_read(&v)) { | while (!atomic_read_xxx(&v)) { > > ... | ... > > cpu_relax_no_barrier(); | > > cpu_relax_no_barrier(); > > order_atomic(&v); | } > > } | > > > > (where order_atomic() is an atomic_t > > specific wrapper as you mentioned below) > > > > ? > > I think the LHS is better if your atomic_read_xxx primitive is using the > crazy one-sided barrier, ^^^^^ I'd say it's purposefully one-sided. > because the LHS code you immediately know what > barriers are happening, and with the RHS you have to look at the > atomic_read_xxx > definition. No. As I said, the _xxx (whatever the heck you want to name it as) should give the same heads-up that your "order_atomic" thing is supposed to give. > If your atomic_read_xxx implementation was more intuitive, then both are > pretty well equal. More lines != ugly code. > > > [...] > > What bugs? > > You can't think for yourself? Your atomic_read_volatile contains a compiler > barrier to the atomic variable before the load. 2 such reads from different > locations look like this: > > asm volatile("" : "+m" (v1)); > atomic_read(&v1); > asm volatile("" : "+m" (v2)); > atomic_read(&v2); > > Which implies that the load of v1 can be reordered to occur after the load > of v2. And how would that be a bug? (sorry, I really can't think for myself) > > > Secondly, what sort of code would do such a thing? > > > > See the nodemgr_host_thread() that does something similar, though not > > exactly same. > > I'm sorry, all this waffling about made up code which might do this and > that is just a waste of time. First, you could try looking at the code. And by the way, as I've already said (why do *require* people to have to repeat things to you?) this isn't even about only existing code. - 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/