From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752847AbbINMCM (ORCPT ); Mon, 14 Sep 2015 08:02:12 -0400 Received: from casper.infradead.org ([85.118.1.10]:36239 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751507AbbINMCK (ORCPT ); Mon, 14 Sep 2015 08:02:10 -0400 Date: Mon, 14 Sep 2015 14:01:53 +0200 From: Peter Zijlstra To: Will Deacon Cc: "Paul E. McKenney" , Boqun Feng , "linux-kernel@vger.kernel.org" , "linuxppc-dev@lists.ozlabs.org" , Ingo Molnar , Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Thomas Gleixner , Waiman Long Subject: Re: [RFC 3/5] powerpc: atomic: implement atomic{,64}_{add,sub}_return_* variants Message-ID: <20150914120153.GY18673@twins.programming.kicks-ass.net> References: <1440730099-29133-4-git-send-email-boqun.feng@gmail.com> <20150828104854.GB16853@twins.programming.kicks-ass.net> <20150828120614.GC29325@fixme-laptop.cn.ibm.com> <20150828141602.GA924@fixme-laptop.cn.ibm.com> <20150828153921.GF19282@twins.programming.kicks-ass.net> <20150901190027.GP1612@arm.com> <20150901214540.GI4029@linux.vnet.ibm.com> <20150902095906.GC25720@arm.com> <20150911124507.GB16833@arm.com> <20150914113520.GP18489@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150914113520.GP18489@twins.programming.kicks-ass.net> User-Agent: Mutt/1.5.21 (2012-12-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Sep 14, 2015 at 01:35:20PM +0200, Peter Zijlstra wrote: > > Sorry for being tardy, I had a wee spell of feeling horrible and then I > procrastinated longer than I should have. > > On Fri, Sep 11, 2015 at 01:45:07PM +0100, Will Deacon wrote: > > > Peter, any thoughts? I'm not au fait with the x86 memory model, but what > > Paul's saying is worrying. > > Right, so Paul is right -- and I completely forgot (I used to know about > that). > > So all the TSO archs (SPARC-TSO, x86 (!OOSTORE) and s390) can do > smp_load_acquire()/smp_store_release() with just barrier(), and while: > > smp_store_release(&x); > smp_load_acquire(&x); > > will provide full order by means of the address dependency, > > smp_store_release(&x); > smp_load_acquire(&y); > > will not. Because the one reorder TSO allows is exactly that one. > > > Peter -- if the above reordering can happen on x86, then moving away > > from RCpc is going to be less popular than I hoped... > > Sadly yes.. We could of course try and split LOCK from ACQUIRE again, > but I'm not sure that's going to help anything except confusion. This of course also means we need something like: smp_mb__release_acquire() which cannot be a no-op for TSO archs. And it might even mean it needs to be the same as smp_mb__unlock_lock(), but I need to think more on this. The scenario is: CPU0 CPU1 unlock(x) smp_store_release(&x->lock, 0); unlock(y) smp_store_release(&next->lock, 1); /* next == &y */ lock(y) while (!(smp_load_acquire(&y->lock)) cpu_relax(); Where the lock does _NOT_ issue a store to acquire the lock at all. Now I don't think any of our current primitives manage this, so we should be good, but it might just be possible. And at the same time; having both: smp_mb__release_acquire() smp_mb__unlock_lock() is quite horrible, for it clearly shows a LOCK isn't quite the same as ACQUIRE :/