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 37584C77B6F for ; Tue, 11 Apr 2023 13:44:47 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4PwnC137Yfz3cdj for ; Tue, 11 Apr 2023 23:44:45 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.a=rsa-sha256 header.s=Intel header.b=aF0AKJCu; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=intel.com (client-ip=192.55.52.43; helo=mga05.intel.com; envelope-from=dave.hansen@intel.com; receiver=) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.a=rsa-sha256 header.s=Intel header.b=aF0AKJCu; dkim-atps=neutral Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4Pwn9z6Gm4z2yHZ for ; Tue, 11 Apr 2023 23:43:46 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1681220632; x=1712756632; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=2GeQQq+KcbTCEU+rXh5JGw+yLkL8a8JmHupdRnaoc8M=; b=aF0AKJCuKyTc6LuJt3x50JsZxedHWhD5RILGqoVVIrPf/ufp/noSR6fJ soArdVdYdUJL2I32d6mBucrwHk/ugwMQfjOhXsGpphleeqOSYhc3yrTPn NhvWlAXfhume82IskZHw5RfZcfXtMP6J1WihQl4rPdPX2CgqHJYJ1N8+r 6wS6R1oH1YJHvSiT+ILrGGM+v2HLtglA/dHzs3/IwONZ+FCThkCBOo11w 8tR4g8mfwo30bAKzxI71oOeWKVHHI8MwVl7LqTcsi2s+8PimN1QOj5FQw GJ3PWysIiIjf1toBrdyopn3wj7N41GnMlXqxefJvs2qUh0I74tsVDcH6P Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10677"; a="429905391" X-IronPort-AV: E=Sophos;i="5.98,336,1673942400"; d="scan'208";a="429905391" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Apr 2023 06:43:40 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10677"; a="812566489" X-IronPort-AV: E=Sophos;i="5.98,336,1673942400"; d="scan'208";a="812566489" Received: from gtryonx-mobl.amr.corp.intel.com (HELO [10.209.72.81]) ([10.209.72.81]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Apr 2023 06:43:39 -0700 Message-ID: <1fee0372-3a3b-5e09-38c3-ffb3523fe195@intel.com> Date: Tue, 11 Apr 2023 06:43:39 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: [PATCH v2 0/5] locking: Introduce local{,64}_try_cmpxchg Content-Language: en-US To: Mark Rutland References: <20230405141710.3551-1-ubizjak@gmail.com> <7360ffd2-a5aa-1373-8309-93e71ff36cbb@intel.com> From: Dave Hansen In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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 4/11/23 04:35, Mark Rutland wrote: > 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 for the additional context. I totally agree that there's zero burden here to show a performance increase. If anyone can think of a quick way to do _some_ kind of benchmark on the code being changed and just show that it's free of brown paper bags, it would be appreciated. Nothing crazy, just think of one workload (synthetic or not) that will stress the paths being changed and run it with and without these changes. Make sure there are not surprises. I also agree that it's unlikely to be brown paper bag material.