From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4F02FC433E0 for ; Wed, 27 Jan 2021 22:23:20 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id E345A64D9F for ; Wed, 27 Jan 2021 22:23:19 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E345A64D9F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=F3zhbOlI8Gd08leZYtcXUkFC7eHW/bt6xcbYphyKMfg=; b=zfjuPCP6PoGYfx0799uvXmJ6A dZjHNC07dkmwlHov4s/QTAVdR1Uoy86n1G/F556kasf+TWhndjDfW2SVk7GS1tz2O17t2wLqIFx/K PZzF8K2P/JJPBZ9PppNfyKyw7Uov4yWnIv3pmFZ+hd/T7mOC3XdPB2tJ1fPjuifoTIcRYcmE/QluV tjuz/QfobLgRxKWMMnb/lWLfnMRwObWlONTeozEnG+PL0BDBKoFaUoA0MA2iDmalwl/WsZ1LbyTnT Jtn3NP6Jz7yVCaKKr0t3QFQNZmhbVOGPGIMJYSG/DX6/BaIrzKm8c1p3MwEy9t8niUi+/se/x4VHL vS/3QYSUg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l4tCS-0005VG-Pu; Wed, 27 Jan 2021 22:22:08 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1l4tCP-0005UX-EW for linux-arm-kernel@lists.infradead.org; Wed, 27 Jan 2021 22:22:06 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id 11DAE61601; Wed, 27 Jan 2021 22:22:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1611786124; bh=ibjxoXuujl5mHGAJ4LR3vpxOtWoS8wLc4XA/OntCLhs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=QI8f6A9fMhniIWgd99cQVkiuyMjXtPpbJpFE/gSyELALOS98i3As4WfeaQEOVUSc7 i0MQpk8rcvA5gxJMa8c36l2FEblX0jIHwi4M1V8kbDgSmRa4YxkkB5Uu+SsLQQHWqN YlGX9t85tf7e+wE3whVkER4O6cZacb7k7EIvfKwXpqVHvgqM2Z55q7+w2Em8eQ6mGT nf7ycfb6R8vaYLLHHS59UJUvVnctqeahYJvS3uszHmSdmsnsHHsQgXirK3U056Jbuk 7CHf/GvpHdCOrtoyzoNRn67Q7zO21C13eO1u4WY/Iw9L6cQNqOEciaAqZf4T6VAya7 5IM51Xb7FU1rg== Date: Wed, 27 Jan 2021 22:21:58 +0000 From: Will Deacon To: Alexander A Sverdlin Subject: Re: [PATCH 1/2] qspinlock: Ensure writes are pushed out of core write buffer Message-ID: <20210127222158.GB848@willie-the-truck> References: <20210127200109.16412-1-alexander.sverdlin@nokia.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210127200109.16412-1-alexander.sverdlin@nokia.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210127_172205_654305_FC2CF297 X-CRM114-Status: GOOD ( 21.51 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Peter Zijlstra , Ingo Molnar , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Russell King Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Jan 27, 2021 at 09:01:08PM +0100, Alexander A Sverdlin wrote: > From: Alexander Sverdlin > > Ensure writes are pushed out of core write buffer to prevent waiting code > on another cores from spinning longer than necessary. > > 6 threads running tight spinlock loop competing for the same lock > on 6 cores on MIPS/Octeon do 1000000 iterations... > > before the patch in: 4.3 sec > after the patch in: 1.2 sec If you only have 6 cores, I'm not sure qspinlock makes any sense... > Same 6-core Octeon machine: > sysbench --test=mutex --num-threads=64 --memory-scope=local run > > w/o patch: 1.53s > with patch: 1.28s > > This will also allow to remove the smp_wmb() in > arch/arm/include/asm/mcs_spinlock.h (was it actually addressing the same > issue?). > > Finally our internal quite diverse test suite of different IPC/network > aspects didn't detect any regressions on ARM/ARM64/x86_64. > > Signed-off-by: Alexander Sverdlin > --- > kernel/locking/mcs_spinlock.h | 5 +++++ > kernel/locking/qspinlock.c | 6 ++++++ > 2 files changed, 11 insertions(+) > > diff --git a/kernel/locking/mcs_spinlock.h b/kernel/locking/mcs_spinlock.h > index 5e10153..10e497a 100644 > --- a/kernel/locking/mcs_spinlock.h > +++ b/kernel/locking/mcs_spinlock.h > @@ -89,6 +89,11 @@ void mcs_spin_lock(struct mcs_spinlock **lock, struct mcs_spinlock *node) > return; > } > WRITE_ONCE(prev->next, node); > + /* > + * This is necessary to make sure that the corresponding "while" in the > + * mcs_spin_unlock() doesn't loop forever > + */ > + smp_wmb(); If it loops forever, that's broken hardware design; store buffers need to drain. I don't think we should add unconditional barriers to bodge this. > /* Wait until the lock holder passes the lock down. */ > arch_mcs_spin_lock_contended(&node->locked); > diff --git a/kernel/locking/qspinlock.c b/kernel/locking/qspinlock.c > index cbff6ba..577fe01 100644 > --- a/kernel/locking/qspinlock.c > +++ b/kernel/locking/qspinlock.c > @@ -469,6 +469,12 @@ void queued_spin_lock_slowpath(struct qspinlock *lock, u32 val) > > /* Link @node into the waitqueue. */ > WRITE_ONCE(prev->next, node); > + /* > + * This is necessary to make sure that the corresponding > + * smp_cond_load_relaxed() below (running on another core) > + * doesn't spin forever. > + */ > + smp_wmb(); Likewise. Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel