From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752654AbcKRKQb (ORCPT ); Fri, 18 Nov 2016 05:16:31 -0500 Received: from foss.arm.com ([217.140.101.70]:44154 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751586AbcKRKQ1 (ORCPT ); Fri, 18 Nov 2016 05:16:27 -0500 Date: Fri, 18 Nov 2016 10:16:26 +0000 From: Will Deacon To: Boqun Feng Cc: Peter Zijlstra , gregkh@linuxfoundation.org, keescook@chromium.org, elena.reshetova@intel.com, arnd@arndb.de, tglx@linutronix.de, mingo@kernel.org, hpa@zytor.com, dave@progbits.org, linux-kernel@vger.kernel.org Subject: Re: [RFC][PATCH 7/7] kref: Implement using refcount_t Message-ID: <20161118101626.GB13470@arm.com> References: <20161114173946.501528675@infradead.org> <20161114174446.832175072@infradead.org> <20161115123337.GD12110@tardis.cn.ibm.com> <20161115130154.GX3117@twins.programming.kicks-ass.net> <20161115141909.GJ27541@tardis.cn.ibm.com> <20161117092800.GD3142@twins.programming.kicks-ass.net> <20161117120836.GE22855@arm.com> <20161117161110.GG3117@twins.programming.kicks-ass.net> <20161117163624.GP22855@arm.com> <20161118082634.GD5227@tardis.cn.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161118082634.GD5227@tardis.cn.ibm.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Nov 18, 2016 at 04:26:34PM +0800, Boqun Feng wrote: > On Thu, Nov 17, 2016 at 04:36:24PM +0000, Will Deacon wrote: > > On Thu, Nov 17, 2016 at 05:11:10PM +0100, Peter Zijlstra wrote: > > > On Thu, Nov 17, 2016 at 12:08:36PM +0000, Will Deacon wrote: > > > > All sounds reasonable to me. It's worth pointing out that you can't create > > > > order using a control dependency hanging off the status flag of a > > > > store-conditional, but the code in question here has the dependency from > > > > the loaded value, which is sufficient. > > > > > > Yeah, I'm always surprised by that 'feature'. Is that ARM specific? Or > > > so more LL/SC archs have this? > > > > In general, I'm not sure, but I think PPC does allow for the control > > dependency. > > > > You guys mean the "control dependency" from a sc to subsequent WRITE, > like in the following litmus? > > PPC sc-control > "" > { > 0:r11=x;0:r12=y;0:r3=1;0:r10=0; > 1:r11=x;1:r12=y; > } > > P0 | P1 ; > lwarx r2, r10, r11 | lwz r2, 0(r12) ; > stwcx. r3, r10, r11 | lwsync ; > bne Fail | ; > stw r3, 0(r12) | lwz r1, 0(r11) ; > Fail: | ; > > exists > (1:r2 = 1 /\ x = 1 /\ 1:r1 = 0) > > PPCMEM and herd both said the exists-clause could be triggered > "Sometimes". > > And ISA said: > > """ > Because a Store Conditional instruction may complete before its store > has been performed, a conditional Branch instruction that depends on the > CR0 value set by a Store Conditional instruction does not order the > Store Conditional's store with respect to storage accesses caused by > instructions that follow the Branch. > """ > > So ppc doesn't honor this "control dependency". ;-) Oh, wow! I was feeling like the odd duck after talking to paulmck and Alan Stern about this at LPC, but now it looks like I have company on the island of misfit memory models. Will