Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp2734845pxb; Tue, 9 Mar 2021 09:32:49 -0800 (PST) X-Google-Smtp-Source: ABdhPJzFicp/QqhVD/js9oJfPYvv298UugLGODKU9Fsr5h2awcWbBYXAFofrJSwKc1Xel6gVXpg9 X-Received: by 2002:a05:6402:4309:: with SMTP id m9mr5599274edc.25.1615311169626; Tue, 09 Mar 2021 09:32:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1615311169; cv=none; d=google.com; s=arc-20160816; b=KcSdULSgzrw2MLHdHHxsOwBLD+AsSvPXWwnV6Plhx77BkX9eD3vHzqMBUiBDjBVvKJ p1Ttu2GU6hx1x71J6hSxvRmwT6viEDLedymU9NH/ogeCCgFI0pg7KOlrKiS1ZLKb2idl uRALvcJ3/h/8ev1Hoj2lVYPAAbLx03hzIHzl3K74xnVc/7QofFqgMT/O/6RCHRAmEiOM eGGdCBRhYlCdLrX+pJnYNRwG/Mu8Z7djl/nPgax/ikkqdHHxfIgy1qazMxeFVYZnbWxu HojvHdhw6VKIrgI2CTfSwhQHKWry4CfUhM2jLBkmT4jkbZlx81L3Jrkbt67wCRTnMoVG 3h7w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=3WUS4pGRIQpMsS0R2Nu/0WV7LIrYLJI+mOOct4C1Pus=; b=rGiO94uoijrwx74sSav2dkTQQGfiSmp4c6VEd9qrsc1gnsbqhyrT0kCzCCqvf65yXd UeQJ+Q5yvcH+nnHNyLj7aMw2nwIi13stY+X1V+hl99/HOWrP5JjiK70sbPKeric9bG2p hNmEGWgUqhF4vEqENDQaKJooaaLU3FwZLEqCbpt1/Of8mHaonCXmBX3f4wmOSXRLEnQ1 Ax4NiF8S6ZmwJkBSyTjdmHjqehiOqDa5ArNS5uZ3NCxUHJsgl9DJZxIioZ677kfNhbd4 Uv5k+ruaeZC9VL7I5RZJTIsOrR2M+P4WrQz0A5FXeAbAhb1mN9fCwjxEYLPgXOvTy9cf RYhQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id hb37si9952951ejc.81.2021.03.09.09.32.24; Tue, 09 Mar 2021 09:32:49 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231362AbhCIRaw (ORCPT + 99 others); Tue, 9 Mar 2021 12:30:52 -0500 Received: from mx2.suse.de ([195.135.220.15]:46884 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230359AbhCIRa2 (ORCPT ); Tue, 9 Mar 2021 12:30:28 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id A3684ACC6; Tue, 9 Mar 2021 17:30:27 +0000 (UTC) Date: Tue, 9 Mar 2021 18:30:26 +0100 From: Michal =?iso-8859-1?Q?Such=E1nek?= To: Davidlohr Bueso Cc: npiggin@gmail.com, Davidlohr Bueso , peterz@infradead.org, linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, mingo@redhat.com, paulus@samba.org, longman@redhat.com, will@kernel.org Subject: Re: [PATCH 3/3] powerpc/qspinlock: Use generic smp_cond_load_relaxed Message-ID: <20210309173026.GB6564@kitsune.suse.cz> References: <20210309015950.27688-1-dave@stgolabs.net> <20210309015950.27688-4-dave@stgolabs.net> <20210309093912.GW6564@kitsune.suse.cz> <20210309154611.kbxzx65auzvmfqnt@offworld> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20210309154611.kbxzx65auzvmfqnt@offworld> User-Agent: Mutt/1.11.3 (2019-02-01) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 09, 2021 at 07:46:11AM -0800, Davidlohr Bueso wrote: > On Tue, 09 Mar 2021, Michal Such�nek wrote: > > > On Mon, Mar 08, 2021 at 05:59:50PM -0800, Davidlohr Bueso wrote: > > > 49a7d46a06c3 (powerpc: Implement smp_cond_load_relaxed()) added > > > busy-waiting pausing with a preferred SMT priority pattern, lowering > > > the priority (reducing decode cycles) during the whole loop slowpath. > > > > > > However, data shows that while this pattern works well with simple > > ^^^^^^^^^^^^^^^^^^^^^^ > > > spinlocks, queued spinlocks benefit more being kept in medium priority, > > > with a cpu_relax() instead, being a low+medium combo on powerpc. > > ... > > > > > > diff --git a/arch/powerpc/include/asm/barrier.h b/arch/powerpc/include/asm/barrier.h > > > index aecfde829d5d..7ae29cfb06c0 100644 > > > --- a/arch/powerpc/include/asm/barrier.h > > > +++ b/arch/powerpc/include/asm/barrier.h > > > @@ -80,22 +80,6 @@ do { \ > > > ___p1; \ > > > }) > > > > > > -#ifdef CONFIG_PPC64 > > Maybe it should be kept for the simple spinlock case then? > > It is kept, note that simple spinlocks don't use smp_cond_load_relaxed, > but instead deal with the priorities in arch_spin_lock(), so it will > spin in low priority until it sees a chance to take the lock, where > it switches back to medium. Indeed, thanks for the clarification. Michal