Received: by 10.213.65.68 with SMTP id h4csp743448imn; Fri, 6 Apr 2018 08:10:15 -0700 (PDT) X-Google-Smtp-Source: AIpwx4//q1J2bbknVr7O6RaN6wD0yH2cI2mfCD97JtfDamteplAHp/Mn9Nys1DDLPganjT5boebK X-Received: by 10.98.69.217 with SMTP id n86mr18941050pfi.41.1523027415655; Fri, 06 Apr 2018 08:10:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523027415; cv=none; d=google.com; s=arc-20160816; b=sYjxX8L5Hdb0aZc5Q2RaT8WfDI6qlWYJilNINmmk2Guc2SQ5Rm/xYy0bSZTZnCfPKN ocpMHXoxSkjbvdieUJw3SeP//xOHbKKjnOXxMQaAsbif0cRj/0BrMZxJJ7nUe/3bCoNS QpKFsZst7Oq45X2XQ8BCYfwprHlisQI0fuzRLVZ+QFIfsluVPKs/4HeYJ/J+LLIPH1Sp eP5EuZwMLN5gWCDIaJnFup644BAj47NtzGCALVf0rCI2IqcLqxS55Lcv7EPUD4vRtYGd fZusTSlzHR2y+4yIGN4PIsnxQLgjBeMjxEbFuvpDvOi9at+8xN867WH6+RNOlr93PS2V e3qA== 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=r8CLipjk4HCwilPLFWkPKw8oT+//mRX17gwA6WBSZoQ=; b=EcraeyuZVCo5XOP2KqHwH+muSOElJns2oyW1oI8QUcXQuYeB8EOojLtNo/zIhgG8Yw C427RRwbefipDOOO2qMRy6BcUFtJFR8MZMrfj9WtEoeIJIDgn09D8eRE1CT+GPtHzq3u Ol9RVvXLF2nnNJeIwogVlnKHRKAPaTMxrF5QI8NRhc3Nx+SrsgDMxK8tAZewEI0QWri0 ghJ55IdKQ9h7TwWa4ABGn4pQu1CO5NIwQzQCEUSTXyjpTbfO0+xkdYVm3z422iS7D9EJ VpurieuWmxJs8m1Fp1GY862d+H+my5+ouCr5xZwKoGSFdhK2xUEXjPfXTIscU+gVfV9G piXg== 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 f34-v6si8762358ple.622.2018.04.06.08.09.31; Fri, 06 Apr 2018 08:10:15 -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 S1751447AbeDFPIJ (ORCPT + 99 others); Fri, 6 Apr 2018 11:08:09 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:38408 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751362AbeDFPIG (ORCPT ); Fri, 6 Apr 2018 11:08:06 -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 CA60515AD; Fri, 6 Apr 2018 08:08:05 -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 9C8083F587; Fri, 6 Apr 2018 08:08:05 -0700 (PDT) Received: by edgewater-inn.cambridge.arm.com (Postfix, from userid 1000) id 9108A1AE55CC; Fri, 6 Apr 2018 16:08:19 +0100 (BST) Date: Fri, 6 Apr 2018 16:08:19 +0100 From: Will Deacon To: Waiman Long Cc: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, peterz@infradead.org, mingo@kernel.org, boqun.feng@gmail.com, paulmck@linux.vnet.ibm.com, catalin.marinas@arm.com Subject: Re: [PATCH 02/10] locking/qspinlock: Remove unbounded cmpxchg loop from locking slowpath Message-ID: <20180406150819.GB10528@arm.com> References: <1522947547-24081-1-git-send-email-will.deacon@arm.com> <1522947547-24081-3-git-send-email-will.deacon@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Thu, Apr 05, 2018 at 05:16:16PM -0400, Waiman Long wrote: > On 04/05/2018 12:58 PM, Will Deacon wrote: > > /* > > - * we're pending, wait for the owner to go away. > > - * > > - * *,1,1 -> *,1,0 > > - * > > - * this wait loop must be a load-acquire such that we match the > > - * store-release that clears the locked bit and create lock > > - * sequentiality; this is because not all clear_pending_set_locked() > > - * implementations imply full barriers. > > - */ > > - smp_cond_load_acquire(&lock->val.counter, !(VAL & _Q_LOCKED_MASK)); > > - > > - /* > > - * take ownership and clear the pending bit. > > - * > > - * *,1,0 -> *,0,1 > > + * If pending was clear but there are waiters in the queue, then > > + * we need to undo our setting of pending before we queue ourselves. > > */ > > - clear_pending_set_locked(lock); > > - return; > > + if (!(val & _Q_PENDING_MASK)) > > + atomic_andnot(_Q_PENDING_VAL, &lock->val); > Can we add a clear_pending() helper that will just clear the byte if > _Q_PENDING_BITS == 8? That will eliminate one atomic instruction from > the failure path. Good idea! Will