Received: by 2002:a05:6358:a55:b0:ec:fcf4:3ecf with SMTP id 21csp3404547rwb; Mon, 16 Jan 2023 07:35:55 -0800 (PST) X-Google-Smtp-Source: AMrXdXtKQS5cQWxhk1KFipyJkKe16lJSfPTWclyL6MOTzkDjcz0TNb4b5U8ENIWjEC89GCLTRT8Y X-Received: by 2002:a17:906:510:b0:872:cc4:f036 with SMTP id j16-20020a170906051000b008720cc4f036mr865481eja.57.1673883355392; Mon, 16 Jan 2023 07:35:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1673883355; cv=none; d=google.com; s=arc-20160816; b=jiT+t7yTBEMNb05v18onqGYOUXdmjEGYmbkvs7+SRKb9gvwshUrib1sQPbjQ8lupFG ShSn1690TFW4cJlFQ62x2ERlpus/rDP0ygpA8Y6P3o1uOjtYVC5q4ALHT72edhkLXYEK n7ZCqIFLDxylHw/+VXaHhJOoGekV876YVvqx8jBDnLpwP0vzsV7IW3PpFHIrzHDbLtv5 IxjD8ypxf9kK0OGLLKfD+aYVyA4aLbNIMBoAxxAqOusGwis8AFvAnsFxDb804Jx29Kkz 6b/iczjsejQHmy6iYp9r3/yyj8PxI5a4B9i3MnukW4uvqg/StlWVu5iuqEyGt265akhP +vzQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=GfCbswdGiY5QLUN/H/9CxTSF8peBR6NpK+RT1su2kro=; b=VBHQ7OXpBP3RWXZqxZoSiRfdg9UzxWfBHfK0JtyA6+2oqUp27jAw4nHmBQR49Zr3FG 7dGVLdznS0FSmHH8l4++uZKGXbjQE+eP+IjuxvE9WdFrJn51ZOAo9FeRGukH95bi/uoJ IrUHEneKTwWXBXP0Y/Z9A/tE4W7W9G4v733hapaxAKK4YPIxGvvIwOXBaunxqxJcCrMH 1LlZgDkm5M16rekqTfqplRCDDl9am36mLlXxy2xhsQ4FNtEyuTiAFASxGkuzLhbkOUGk N1OX/waaBvyjml1GTKr1sD+5Lo4WyyFbk53tKSiuX5zRk6PLFPfuZYDvkkm7KFt1hGVW O0iQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=ozj1DVL3; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id js10-20020a17090797ca00b007707b853e46si355904ejc.882.2023.01.16.07.35.42; Mon, 16 Jan 2023 07:35:55 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=ozj1DVL3; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232274AbjAPONF (ORCPT + 50 others); Mon, 16 Jan 2023 09:13:05 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57034 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232334AbjAPOMK (ORCPT ); Mon, 16 Jan 2023 09:12:10 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 55CB72BF24; Mon, 16 Jan 2023 06:04:45 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id BCA23B80E93; Mon, 16 Jan 2023 14:04:43 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7140AC433F2; Mon, 16 Jan 2023 14:04:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1673877882; bh=wGOzJL29GJYJd5eJYqgiIGm2R4h4WfIptHWTivlXHO8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ozj1DVL3CSLGP5h6fl/oJCHZSax48dhCkeGxs0iEZLbSIMbg1bGy+9vhQLreyiyCy BE3lAxJ1JsLFO6X8NKlTuVza5i2FYs6dzITlFLD2E54kK4vSkQYcmWKMu9U91Hd9RR nBHUT4ebgS8YevKimAxvkj857p87zeeURl7Ijnk1eGhKCpEWbEvA6YW9c8qKFX3h6g Jdkib5xpUohsUXqY/u6dHOF2t+rYpDU1UD8kLB0MWrNREAxVCrmUqvYVUMwFw1Vf6e 9IJBqldf2rTJjX89Z/sG8548aE/jRNHAclyKXvRU4bVbrQsPSnBB8nTSp+nUCByjPR 6jYoDoJxgH1Vg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Mateusz Guzik , Tony Luck , Nicholas Piggin , Will Deacon , Peter Zijlstra , Linus Torvalds , Sasha Levin , ubizjak@gmail.com Subject: [PATCH AUTOSEL 5.15 23/24] lockref: stop doing cpu_relax in the cmpxchg loop Date: Mon, 16 Jan 2023 09:03:58 -0500 Message-Id: <20230116140359.115716-23-sashal@kernel.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20230116140359.115716-1-sashal@kernel.org> References: <20230116140359.115716-1-sashal@kernel.org> MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Mateusz Guzik [ Upstream commit f5fe24ef17b5fbe6db49534163e77499fb10ae8c ] On the x86-64 architecture even a failing cmpxchg grants exclusive access to the cacheline, making it preferable to retry the failed op immediately instead of stalling with the pause instruction. To illustrate the impact, below are benchmark results obtained by running various will-it-scale tests on top of the 6.2-rc3 kernel and Cascade Lake (2 sockets * 24 cores * 2 threads) CPU. All results in ops/s. Note there is some variance in re-runs, but the code is consistently faster when contention is present. open3 ("Same file open/close"): proc stock no-pause 1 805603 814942 (+%1) 2 1054980 1054781 (-0%) 8 1544802 1822858 (+18%) 24 1191064 2199665 (+84%) 48 851582 1469860 (+72%) 96 609481 1427170 (+134%) fstat2 ("Same file fstat"): proc stock no-pause 1 3013872 3047636 (+1%) 2 4284687 4400421 (+2%) 8 3257721 5530156 (+69%) 24 2239819 5466127 (+144%) 48 1701072 5256609 (+209%) 96 1269157 6649326 (+423%) Additionally, a kernel with a private patch to help access() scalability: access2 ("Same file access"): proc stock patched patched +nopause 24 2378041 2005501 5370335 (-15% / +125%) That is, fixing the problems in access itself *reduces* scalability after the cacheline ping-pong only happens in lockref with the pause instruction. Note that fstat and access benchmarks are not currently integrated into will-it-scale, but interested parties can find them in pull requests to said project. Code at hand has a rather tortured history. First modification showed up in commit d472d9d98b46 ("lockref: Relax in cmpxchg loop"), written with Itanium in mind. Later it got patched up to use an arch-dependent macro to stop doing it on s390 where it caused a significant regression. Said macro had undergone revisions and was ultimately eliminated later, going back to cpu_relax. While I intended to only remove cpu_relax for x86-64, I got the following comment from Linus: I would actually prefer just removing it entirely and see if somebody else hollers. You have the numbers to prove it hurts on real hardware, and I don't think we have any numbers to the contrary. So I think it's better to trust the numbers and remove it as a failure, than say "let's just remove it on x86-64 and leave everybody else with the potentially broken code" Additionally, Will Deacon (maintainer of the arm64 port, one of the architectures previously benchmarked): So, from the arm64 side of the fence, I'm perfectly happy just removing the cpu_relax() calls from lockref. As such, come back full circle in history and whack it altogether. Signed-off-by: Mateusz Guzik Link: https://lore.kernel.org/all/CAGudoHHx0Nqg6DE70zAVA75eV-HXfWyhVMWZ-aSeOofkA_=WdA@mail.gmail.com/ Acked-by: Tony Luck # ia64 Acked-by: Nicholas Piggin # powerpc Acked-by: Will Deacon # arm64 Acked-by: Peter Zijlstra Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin --- lib/lockref.c | 1 - 1 file changed, 1 deletion(-) diff --git a/lib/lockref.c b/lib/lockref.c index 5b34bbd3eba8..81ac5f355242 100644 --- a/lib/lockref.c +++ b/lib/lockref.c @@ -24,7 +24,6 @@ } \ if (!--retry) \ break; \ - cpu_relax(); \ } \ } while (0) -- 2.35.1