Received: by 10.213.65.68 with SMTP id h4csp2462201imn; Mon, 9 Apr 2018 04:02:20 -0700 (PDT) X-Google-Smtp-Source: AIpwx49v0W1Z7cGPrO86G6JpG1iKBDM5rHSftr0dUyGKJjSn1DeFaRIBvHcngGTqXDH7JatcykHa X-Received: by 2002:a17:902:59c9:: with SMTP id d9-v6mr38704438plj.251.1523271740266; Mon, 09 Apr 2018 04:02:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523271740; cv=none; d=google.com; s=arc-20160816; b=seEvHrJcu36TuT0hPXs+CW9GD9+QY03sjSUUVEykmBCOfGDYEChSLiG+TloB9oKa8N 0Gryfb3gATgaDeeOQxCBybWs7XomuSWeL+SH0N9s4PZbUGX19e4pfSzVn/Uigmvb7IwV bfpwt5EJbLJf8mMBI+JiJKAV3fsZoOnUMdUyytSPVlZFzFBDJnS2mO6fDRUfHSmpltut OFVQfGJfiWKDssr9o3ihSLp2VgZ8BZgb8QVhHGf9k5ZM1S1j2E+YSCWcUQJ+OhwXZzpB GmQjGCWY4MlDLW3/AK2dg/ge2AYUSndGB2crwOf0jlI8BpQ0CndT1gGGGOr/b7xKBkz0 igkA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=dQm9aeqKh2Vr+3jZCE9J1V404cuTGLRMMko/KS1dtrM=; b=lgYqTDztAhlSgCm2jG1dDY0RFCuBxbA8ocvUfnFGhqa2nlBoiCiJBWbBRZNRwQ8W+Z wmy03Q9DLN6/tESaFJHw5ffGCeY57UMzJ7msfKgOfOsrjTtjrENLjfdnKDg7qmOPK1B1 yvHP6lQQiOo8FNutKKfE5T9NFNFvm5RhybUoqe0+gXQ33+rFxWnnpdpKjiHnazbIPWTK ScGouo+iHTePRuFEDhY+oaXQegEAOioxvy4FZHhGotvxGkftuZfIItVt95xQTkS/2Dyc RCFne4gOXKZdtLfWNjOMPLLMnOuJ7SU3Ugmvt+RKfLJWwWbJwVtEkfPVDuXYrqGCMvh+ yitQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f3-v6si6731pld.687.2018.04.09.04.01.43; Mon, 09 Apr 2018 04:02:20 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751954AbeDIK63 (ORCPT + 99 others); Mon, 9 Apr 2018 06:58:29 -0400 Received: from foss.arm.com ([217.140.101.70]:54646 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751270AbeDIK60 (ORCPT ); Mon, 9 Apr 2018 06:58:26 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 2AF601596; Mon, 9 Apr 2018 03:58:26 -0700 (PDT) Received: from edgewater-inn.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id F0FD23F487; Mon, 9 Apr 2018 03:58:25 -0700 (PDT) Received: by edgewater-inn.cambridge.arm.com (Postfix, from userid 1000) id C72001AE552D; Mon, 9 Apr 2018 11:58:40 +0100 (BST) Date: Mon, 9 Apr 2018 11:58:40 +0100 From: Will Deacon To: Peter Zijlstra Cc: "Paul E. McKenney" , Waiman Long , 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: <20180409105840.GD23134@arm.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> <20180407084732.GO4082@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180407084732.GO4082@hirez.programming.kicks-ass.net> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Apr 07, 2018 at 10:47:32AM +0200, Peter Zijlstra wrote: > 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. We need to get to the bottom of this, otherwise we're just relying on Waiman's testing to validate any changes to this code! Will