Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755413Ab3H3Cfo (ORCPT ); Thu, 29 Aug 2013 22:35:44 -0400 Received: from mail-vc0-f177.google.com ([209.85.220.177]:63897 "EHLO mail-vc0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751962Ab3H3Cfm (ORCPT ); Thu, 29 Aug 2013 22:35:42 -0400 MIME-Version: 1.0 In-Reply-To: <1377829857.4028.46.camel@pasglop> References: <1375758759-29629-1-git-send-email-Waiman.Long@hp.com> <1375758759-29629-2-git-send-email-Waiman.Long@hp.com> <1377751465.4028.20.camel@pasglop> <20130829070012.GC27322@gmail.com> <1377822408.4028.44.camel@pasglop> <29797.1377828380@ale.ozlabs.ibm.com> <1377829857.4028.46.camel@pasglop> Date: Thu, 29 Aug 2013 19:35:41 -0700 X-Google-Sender-Auth: mqwHYWzJu5bUbwLpqIfTavQrcAk Message-ID: Subject: Re: [PATCH v7 1/4] spinlock: A new lockref structure for lockless update of refcount From: Linus Torvalds To: Benjamin Herrenschmidt Cc: Michael Neuling , Ingo Molnar , Waiman Long , Alexander Viro , Jeff Layton , Miklos Szeredi , Ingo Molnar , Thomas Gleixner , linux-fsdevel , Linux Kernel Mailing List , Peter Zijlstra , Steven Rostedt , Andi Kleen , "Chandramouleeswaran, Aswin" , "Norton, Scott J" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1065 Lines: 24 On Thu, Aug 29, 2013 at 7:30 PM, Benjamin Herrenschmidt wrote: > > Or we can keep both completely separate like Linus does on x86. I did it that way mainly to minimize the patch. I agree with you that it probably makes sense to layer them the other way around from what Michael's patch did, iow implement arch_spin_is_locked() in terms of arch_spin_value_unlocked(). That said, on power, you have that "ACCESS_ONCE()" implicit in the *type*, not in the code, so an "arch_spinlock_t" is fundamentally volatile in itself. It's one of the reasons I despise "volatile": things like volatility are _not_ attributes of a variable or a type, but of the code in question. Something can be volatile in one context, but not in another (one context might be locked, for example). Linus -- 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/