From mboxrd@z Thu Jan 1 00:00:00 1970 From: peterz@infradead.org (Peter Zijlstra) Date: Sat, 7 Apr 2018 10:47:32 +0200 Subject: [PATCH 02/10] locking/qspinlock: Remove unbounded cmpxchg loop from locking slowpath In-Reply-To: <20180406210953.GA24165@linux.vnet.ibm.com> References: <1522947547-24081-1-git-send-email-will.deacon@arm.com> <1522947547-24081-3-git-send-email-will.deacon@arm.com> <20180406210953.GA24165@linux.vnet.ibm.com> Message-ID: <20180407084732.GO4082@hirez.programming.kicks-ass.net> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Fri, Apr 06, 2018 at 02:09:53PM -0700, Paul E. McKenney wrote: > It would indeed be good to not be in the position of having to trade off > forward-progress guarantees against performance, but that does appear to > be where we are at the moment. Depends of course on how unfair cmpxchg is. On x86 we trade one cmpxchg loop for another so the patch doesn't cure anything at all there. And our cmpxchg has 'some' hardware fairness to it. So while the patch is 'good' for platforms that have native fetch-or, it doesn't help (or in our case even hurts) those that do not. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751334AbeDGIrj (ORCPT ); Sat, 7 Apr 2018 04:47:39 -0400 Received: from bombadil.infradead.org ([198.137.202.133]:33252 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751064AbeDGIri (ORCPT ); Sat, 7 Apr 2018 04:47:38 -0400 Date: Sat, 7 Apr 2018 10:47:32 +0200 From: Peter Zijlstra To: "Paul E. McKenney" Cc: Waiman Long , Will Deacon , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, mingo@kernel.org, boqun.feng@gmail.com, catalin.marinas@arm.com Subject: Re: [PATCH 02/10] locking/qspinlock: Remove unbounded cmpxchg loop from locking slowpath Message-ID: <20180407084732.GO4082@hirez.programming.kicks-ass.net> References: <1522947547-24081-1-git-send-email-will.deacon@arm.com> <1522947547-24081-3-git-send-email-will.deacon@arm.com> <20180406210953.GA24165@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180406210953.GA24165@linux.vnet.ibm.com> User-Agent: Mutt/1.9.3 (2018-01-21) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Apr 06, 2018 at 02:09:53PM -0700, Paul E. McKenney wrote: > It would indeed be good to not be in the position of having to trade off > forward-progress guarantees against performance, but that does appear to > be where we are at the moment. Depends of course on how unfair cmpxchg is. On x86 we trade one cmpxchg loop for another so the patch doesn't cure anything at all there. And our cmpxchg has 'some' hardware fairness to it. So while the patch is 'good' for platforms that have native fetch-or, it doesn't help (or in our case even hurts) those that do not.