Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932942AbcDYPh0 (ORCPT ); Mon, 25 Apr 2016 11:37:26 -0400 Received: from bombadil.infradead.org ([198.137.202.9]:57090 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932844AbcDYPhV (ORCPT ); Mon, 25 Apr 2016 11:37:21 -0400 Date: Mon, 25 Apr 2016 17:37:10 +0200 From: Peter Zijlstra To: Pan Xinhui Cc: linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, benh@kernel.crashing.org, paulus@samba.org, mpe@ellerman.id.au, boqun.feng@gmail.com, paulmck@linux.vnet.ibm.com, tglx@linutronix.de Subject: Re: [PATCH V3] powerpc: Implement {cmp}xchg for u8 and u16 Message-ID: <20160425153710.GG3448@twins.programming.kicks-ass.net> References: <5715D04E.9050009@linux.vnet.ibm.com> <571782F0.2020201@linux.vnet.ibm.com> <20160420142408.GF3430@twins.programming.kicks-ass.net> <5718F32B.3050409@linux.vnet.ibm.com> <20160421161354.GI3430@twins.programming.kicks-ass.net> <571DED2B.8060600@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <571DED2B.8060600@linux.vnet.ibm.com> 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 Content-Length: 917 Lines: 19 On Mon, Apr 25, 2016 at 06:10:51PM +0800, Pan Xinhui wrote: > > So I'm not actually _that_ familiar with the PPC LL/SC implementation; > > but there are things a CPU can do to optimize these loops. > > > > For example, a CPU might choose to not release the exclusive hold of the > > line for a number of cycles, except when it passes SC or an interrupt > > happens. This way there's a smaller chance the SC fails and inhibits > > forward progress. > I am not sure if there is such hardware optimization. So I think the hardware must do _something_, otherwise competing cores doing load-exlusive could life-lock a system, each one endlessly breaking the exclusive ownership of the other and the store-conditional always failing. Of course, there are such implementations, and they tend to have to put in explicit backoff loops; however, IIRC, PPC doesn't need that. (See ARC for an example that needs to do this.)