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 Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id F3D2AC77B6F for ; Tue, 11 Apr 2023 11:36:59 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4PwkMZ3WhNz3cjN for ; Tue, 11 Apr 2023 21:36:58 +1000 (AEST) Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=arm.com (client-ip=217.140.110.172; helo=foss.arm.com; envelope-from=mark.rutland@arm.com; receiver=) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lists.ozlabs.org (Postfix) with ESMTP id 4PwkM265ltz3bjj for ; Tue, 11 Apr 2023 21:36:29 +1000 (AEST) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 96259D75; Tue, 11 Apr 2023 04:36:42 -0700 (PDT) Received: from FVFF77S0Q05N (unknown [10.57.20.166]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 4DAD93F6C4; Tue, 11 Apr 2023 04:35:53 -0700 (PDT) Date: Tue, 11 Apr 2023 12:35:50 +0100 From: Mark Rutland To: Dave Hansen Subject: Re: [PATCH v2 0/5] locking: Introduce local{,64}_try_cmpxchg Message-ID: References: <20230405141710.3551-1-ubizjak@gmail.com> <7360ffd2-a5aa-1373-8309-93e71ff36cbb@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7360ffd2-a5aa-1373-8309-93e71ff36cbb@intel.com> X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Ian Rogers , x86@kernel.org, Peter Zijlstra , Dave Hansen , Jiaxun Yang , linux-kernel@vger.kernel.org, "H. Peter Anvin" , WANG Xuerui , Will Deacon , linux-arch@vger.kernel.org, Jun Yi , Huacai Chen , Uros Bizjak , Alexander Shishkin , Ingo Molnar , Matt Turner , Arnd Bergmann , Boqun Feng , Richard Henderson , Nicholas Piggin , Ivan Kokshaysky , Arnaldo Carvalho de Melo , loongarch@lists.linux.dev, Namhyung Kim , Thomas Gleixner , Thomas Bogendoerfer , linux-mips@vger.kernel.org, linux-perf-users@vger.kernel .org, Jiri Olsa , linux-alpha@vger.kernel.org, Borislav Petkov , linuxppc-dev@lists.ozlabs.org Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Wed, Apr 05, 2023 at 09:37:04AM -0700, Dave Hansen wrote: > On 4/5/23 07:17, Uros Bizjak wrote: > > Add generic and target specific support for local{,64}_try_cmpxchg > > and wire up support for all targets that use local_t infrastructure. > > I feel like I'm missing some context. > > What are the actual end user visible effects of this series? Is there a > measurable decrease in perf overhead? Why go to all this trouble for > perf? Who else will use local_try_cmpxchg()? Overall, the theory is that it can generate slightly better code (e.g. by reusing the flags on x86). In practice, that might be in the noise, but as demonstrated in prior postings the code generation is no worse than before. >From my perspective, the more important part is that this aligns local_t with the other atomic*_t APIs, which all have ${atomictype}_try_cmpxchg(), and for consistency/legibility/maintainability it's nice to be able to use the same code patterns, e.g. ${inttype} new, old = ${atomictype}_read(ptr); do { ... new = do_something_with(old); } while (${atomictype}_try_cmpxvhg(ptr, &oldval, newval); > I'm all for improving things, and perf is an important user. But, if > the goal here is improving performance, it would be nice to see at least > a stab at quantifying the performance delta. IIUC, Steve's original request for local_try_cmpxchg() was a combination of a theoretical performance benefit and a more general preference to use try_cmpxchg() for consistency / better structure of the source code: https://lore.kernel.org/lkml/20230301131831.6c8d4ff5@gandalf.local.home/ I agree it'd be nice to have performance figures, but I think those would only need to demonstrate a lack of a regression rather than a performance improvement, and I think it's fairly clear from eyeballing the generated instructions that a regression isn't likely. Thanks, Mark.