Message ID | 20221222114635.1251934-1-andrzej.hajda@intel.com |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:e747:0:0:0:0:0 with SMTP id c7csp277875wrn; Thu, 22 Dec 2022 03:50:04 -0800 (PST) X-Google-Smtp-Source: AMrXdXt+EB7LaR07IfmhyED4Qic+rMpiPxn3vj/0NG9bV+t3v3vtqkYkCkqPlI0K0Q9TOOH6H2mW X-Received: by 2002:aa7:da49:0:b0:470:489c:5369 with SMTP id w9-20020aa7da49000000b00470489c5369mr4424854eds.6.1671709804505; Thu, 22 Dec 2022 03:50:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1671709804; cv=none; d=google.com; s=arc-20160816; b=lG0CLy5FYZgyiZzZrhSwpxMhLiurK5JpP9xgvW+4YEJCigdGOBY60FP3B+zN3yabbc ZTYqYS6lcZ842bKgYug/wJ3VwlWBrGd1qYReEt1dP+ddgzeBMgIR4X1lAnSdD+1ZDPC2 a3H0DjXuhrQnRSWI/Y/M2loJF6E7B6xCY0KCougrTDeP2P6sIKr1qwaNVJGSxtVHNMw3 Z+AMIX7OCamRTkrsCBBkrJ0U3HhnmtG6eBPXJvyLLcraWtTL0n5yyS6peo2v+n0dfaR8 GrEa0iYg1df91/6kf0jetJmB2ifOQge3ARJsNBUXqMBCtehe92iCmmwi2LHndDedtQzP Z40g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:organization :mime-version:message-id:date:subject:cc:to:from:dkim-signature; bh=gL/n/26ji7rHwbfnO2JvkCTk0j2SxhXJQjC4zarSE4A=; b=ofUj+WuLN1SFTfpzcQOUc0kWo+lSHDguEOjzGun6mNZYot4SSWwHQKLGN295j+CR0Y 02E3OPbw3yvQM6ZdPuNPF98gS2xEts5xE7+Qwh/XlotMTkVs+cgnhp07Mt3GYGDfUHmT HXhxpJDyDRWxEhlRaBZ5Np1q7070FaVoiwgRisKB8EhNG9QISTpbMuW1dwu7ySypU/ca aJWw24v24TmBpUAKFDcqC7o956ni1uBMQgmJLlunkrm3OhP+tJNcaIn+Tweo18WSC5Cw iZuZSjuh/rK/UystK7zlHs7ncExQlFO7dhvoWM95PUE0DjXrlld9Pizc/2mD0TKCZtME 9VUA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=RrpQORyS; 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=intel.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id bx18-20020a0564020b5200b0046b1d61229esi521620edb.117.2022.12.22.03.49.41; Thu, 22 Dec 2022 03:50:04 -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=@intel.com header.s=Intel header.b=RrpQORyS; 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=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235537AbiLVLra (ORCPT <rfc822;pacteraone@gmail.com> + 99 others); Thu, 22 Dec 2022 06:47:30 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47314 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229548AbiLVLr0 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 22 Dec 2022 06:47:26 -0500 Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BBEB318E1D; Thu, 22 Dec 2022 03:47:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1671709645; x=1703245645; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=jJG0WtbR+rCKPAOFXgAECJpdIQA2qxIhAt/9hS9GHCs=; b=RrpQORyS/I890Lp0DquOSsvUNL1GKaH1JDdSTSfNsl2C1m725bEPTtYd 2gbPUxW6rcwn6XEFWvFWW5Vljmnv1bqmkMYjA4O1Eazo+91b0tyAReZoq Jzo9fDbWXUBuHRqYWWEneTPW4GW4TJMhW2VBV3vKMnfdYzztJJhFGaebP UtUHILqYAS2Hk6ZAaJRPkBPIP4yZZSmNg5AkBl8Kq7mP68UO8EySb/Iqo Muq2mYslgd589BVFyOqvIZZvBwi2BYR9zQZt0q9fDUAzlVtw/MY9lAf+u NeVGoPH4Y/CKHh41k1phIEUbHFYielmoedk8nF9P9Tc2KOONHmYWfyAya Q==; X-IronPort-AV: E=McAfee;i="6500,9779,10568"; a="318804416" X-IronPort-AV: E=Sophos;i="5.96,265,1665471600"; d="scan'208";a="318804416" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Dec 2022 03:47:24 -0800 X-IronPort-AV: E=McAfee;i="6500,9779,10568"; a="629504298" X-IronPort-AV: E=Sophos;i="5.96,265,1665471600"; d="scan'208";a="629504298" Received: from lab-ah.igk.intel.com ([10.91.215.196]) by orsmga006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Dec 2022 03:47:18 -0800 From: Andrzej Hajda <andrzej.hajda@intel.com> To: linux-alpha@vger.kernel.org, linux-kernel@vger.kernel.org, linux-snps-arc@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-hexagon@vger.kernel.org, linux-ia64@vger.kernel.org, loongarch@lists.linux.dev, linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org, openrisc@lists.librecores.org, linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, sparclinux@vger.kernel.org, linux-xtensa@linux-xtensa.org, intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org Cc: Andrzej Hajda <andrzej.hajda@intel.com>, Arnd Bergmann <arnd@arndb.de>, Rodrigo Vivi <rodrigo.vivi@intel.com>, Andrew Morton <akpm@linux-foundation.org>, Andy Shevchenko <andriy.shevchenko@linux.intel.com>, Peter Zijlstra <peterz@infradead.org>, Boqun Feng <boqun.feng@gmail.com>, Mark Rutland <mark.rutland@arm.com> Subject: [PATCH 00/19] Introduce __xchg, non-atomic xchg Date: Thu, 22 Dec 2022 12:46:16 +0100 Message-Id: <20221222114635.1251934-1-andrzej.hajda@intel.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Organization: Intel Technology Poland sp. z o.o. - ul. Slowackiego 173, 80-298 Gdansk - KRS 101882 - NIP 957-07-52-316 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_NONE autolearn=unavailable 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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1752914779713063445?= X-GMAIL-MSGID: =?utf-8?q?1752914779713063445?= |
Series |
Introduce __xchg, non-atomic xchg
|
|
Message
Andrzej Hajda
Dec. 22, 2022, 11:46 a.m. UTC
Hi all, I hope there will be place for such tiny helper in kernel. Quick cocci analyze shows there is probably few thousands places where it could be useful. I am not sure who is good person to review/ack such patches, so I've used my intuition to construct to/cc lists, sorry for mistakes. This is the 2nd approach of the same idea, with comments addressed[0]. The helper is tiny and there are advices we can leave without it, so I want to present few arguments why it would be good to have it: 1. Code readability/simplification/number of lines: Real example from drivers/net/ethernet/mellanox/mlx5/core/esw/qos.c: - previous_min_rate = evport->qos.min_rate; - evport->qos.min_rate = min_rate; + previous_min_rate = __xchg(evport->qos.min_rate, min_rate); For sure the code is more compact, and IMHO more readable. 2. Presence of similar helpers in other somehow related languages/libs: a) Rust[1]: 'replace' from std::mem module, there is also 'take' helper (__xchg(&x, 0)), which is the same as private helper in i915 - fetch_and_zero, see latest patch. b) C++ [2]: 'exchange' from utility header. If the idea is OK there are still 2 qestions to answer: 1. Name of the helper, __xchg follows kernel conventions, but for me Rust names are also OK. 2. Where to put the helper: a) as in this patchset include/linux/non-atomic/xchg.h, proposed by Andy Shevchenko, b) include/linux/utils.h ? any better name? Some kind of container for simple helpers. Structure of the patchset: 17 patches releasing __xchg name from arch files 1 patch adding __xchg 1 patch adding users of __xchg Arnd thanks for convienient set of cross compilers, it was very helpful. So many words for so small helper :) [0]: https://lore.kernel.org/lkml/Y5OFSvaYbv4XCxhE@smile.fi.intel.com/T/ [1]: https://doc.rust-lang.org/std/mem/index.html [2]: https://en.cppreference.com/w/cpp/header/utility Regards Andrzej Andrzej Hajda (19): arch/alpha: rename internal name __xchg to __arch_xchg arch/arc: rename internal name __xchg to __arch_xchg arch/arm: rename internal name __xchg to __arch_xchg arch/arm64: rename internal name __xchg to __arch_xchg arch/hexagon: rename internal name __xchg to __arch_xchg arch/ia64: rename internal name __xchg to __arch_xchg arch/loongarch: rename internal name __xchg to __arch_xchg arch/m68k: rename internal name __xchg to __arch_xchg arch/mips: rename internal name __xchg to __arch_xchg arch/openrisc: rename internal name __xchg to __arch_xchg arch/parisc: rename internal name __xchg to __arch_xchg arch/powerpc: correct logged function names in xchg helpers arch/riscv: rename internal name __xchg to __arch_xchg arch/s390: rename internal name __xchg to __arch_xchg arch/sh: rename internal name __xchg to __arch_xchg arch/sparc: rename internal name __xchg to __arch_xchg arch/xtensa: rename internal name __xchg to __arch_xchg linux/include: add non-atomic version of xchg drm/i915/gt: use __xchg instead of internal helper arch/alpha/include/asm/cmpxchg.h | 6 +++--- arch/arc/include/asm/cmpxchg.h | 4 ++-- arch/arm/include/asm/cmpxchg.h | 4 ++-- arch/arm64/include/asm/cmpxchg.h | 4 ++-- arch/hexagon/include/asm/cmpxchg.h | 6 +++--- arch/ia64/include/asm/cmpxchg.h | 2 +- arch/ia64/include/uapi/asm/cmpxchg.h | 4 ++-- arch/loongarch/include/asm/cmpxchg.h | 4 ++-- arch/m68k/include/asm/cmpxchg.h | 6 +++--- arch/mips/include/asm/cmpxchg.h | 4 ++-- arch/openrisc/include/asm/cmpxchg.h | 4 ++-- arch/parisc/include/asm/cmpxchg.h | 4 ++-- arch/powerpc/include/asm/cmpxchg.h | 4 ++-- arch/riscv/include/asm/atomic.h | 2 +- arch/riscv/include/asm/cmpxchg.h | 4 ++-- arch/s390/include/asm/cmpxchg.h | 4 ++-- arch/sh/include/asm/cmpxchg.h | 4 ++-- arch/sparc/include/asm/cmpxchg_32.h | 4 ++-- arch/sparc/include/asm/cmpxchg_64.h | 4 ++-- arch/xtensa/include/asm/cmpxchg.h | 4 ++-- drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +- .../gpu/drm/i915/gt/intel_engine_heartbeat.c | 4 ++-- .../drm/i915/gt/intel_execlists_submission.c | 4 ++-- drivers/gpu/drm/i915/gt/intel_ggtt.c | 4 ++-- drivers/gpu/drm/i915/gt/intel_gsc.c | 2 +- drivers/gpu/drm/i915/gt/intel_gt.c | 4 ++-- drivers/gpu/drm/i915/gt/intel_gt_pm.c | 2 +- drivers/gpu/drm/i915/gt/intel_lrc.c | 6 +++--- drivers/gpu/drm/i915/gt/intel_migrate.c | 2 +- drivers/gpu/drm/i915/gt/intel_rc6.c | 2 +- drivers/gpu/drm/i915/gt/intel_rps.c | 2 +- drivers/gpu/drm/i915/gt/selftest_context.c | 2 +- .../drm/i915/gt/selftest_ring_submission.c | 2 +- drivers/gpu/drm/i915/gt/selftest_timeline.c | 2 +- drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c | 2 +- drivers/gpu/drm/i915/gt/uc/intel_uc.c | 2 +- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 2 +- drivers/gpu/drm/i915/i915_utils.h | 1 + include/linux/non-atomic/xchg.h | 19 +++++++++++++++++++ 39 files changed, 84 insertions(+), 64 deletions(-) create mode 100644 include/linux/non-atomic/xchg.h
Comments
Hi Andrzej, Thanks for your series! On Thu, Dec 22, 2022 at 12:49 PM Andrzej Hajda <andrzej.hajda@intel.com> wrote: > I hope there will be place for such tiny helper in kernel. > Quick cocci analyze shows there is probably few thousands places > where it could be useful. > I am not sure who is good person to review/ack such patches, > so I've used my intuition to construct to/cc lists, sorry for mistakes. > This is the 2nd approach of the same idea, with comments addressed[0]. > > The helper is tiny and there are advices we can leave without it, so > I want to present few arguments why it would be good to have it: > > 1. Code readability/simplification/number of lines: > > Real example from drivers/net/ethernet/mellanox/mlx5/core/esw/qos.c: > - previous_min_rate = evport->qos.min_rate; > - evport->qos.min_rate = min_rate; > + previous_min_rate = __xchg(evport->qos.min_rate, min_rate); Upon closer look, shouldn't that be previous_min_rate = __xchg(&evport->qos.min_rate, min_rate); ? > For sure the code is more compact, and IMHO more readable. > > 2. Presence of similar helpers in other somehow related languages/libs: > > a) Rust[1]: 'replace' from std::mem module, there is also 'take' > helper (__xchg(&x, 0)), which is the same as private helper in > i915 - fetch_and_zero, see latest patch. > b) C++ [2]: 'exchange' from utility header. > > If the idea is OK there are still 2 qestions to answer: > > 1. Name of the helper, __xchg follows kernel conventions, > but for me Rust names are also OK. Before I realized the missing "&", I wondered how this is different from swap(), so naming is important. https://elixir.bootlin.com/linux/latest/source/include/linux/minmax.h#L139 Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
On 22.12.2022 15:12, Geert Uytterhoeven wrote: > Hi Andrzej, > > Thanks for your series! > > On Thu, Dec 22, 2022 at 12:49 PM Andrzej Hajda <andrzej.hajda@intel.com> wrote: >> I hope there will be place for such tiny helper in kernel. >> Quick cocci analyze shows there is probably few thousands places >> where it could be useful. >> I am not sure who is good person to review/ack such patches, >> so I've used my intuition to construct to/cc lists, sorry for mistakes. >> This is the 2nd approach of the same idea, with comments addressed[0]. >> >> The helper is tiny and there are advices we can leave without it, so >> I want to present few arguments why it would be good to have it: >> >> 1. Code readability/simplification/number of lines: >> >> Real example from drivers/net/ethernet/mellanox/mlx5/core/esw/qos.c: >> - previous_min_rate = evport->qos.min_rate; >> - evport->qos.min_rate = min_rate; >> + previous_min_rate = __xchg(evport->qos.min_rate, min_rate); > Upon closer look, shouldn't that be > > previous_min_rate = __xchg(&evport->qos.min_rate, min_rate); > > ? Yes, you are right, the first argument is a pointer. Regards Andrzej > >> For sure the code is more compact, and IMHO more readable. >> >> 2. Presence of similar helpers in other somehow related languages/libs: >> >> a) Rust[1]: 'replace' from std::mem module, there is also 'take' >> helper (__xchg(&x, 0)), which is the same as private helper in >> i915 - fetch_and_zero, see latest patch. >> b) C++ [2]: 'exchange' from utility header. >> >> If the idea is OK there are still 2 qestions to answer: >> >> 1. Name of the helper, __xchg follows kernel conventions, >> but for me Rust names are also OK. > Before I realized the missing "&", I wondered how this is different > from swap(), so naming is important. > https://elixir.bootlin.com/linux/latest/source/include/linux/minmax.h#L139 > > Gr{oetje,eeting}s, > > Geert > > -- > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org > > In personal conversations with technical people, I call myself a hacker. But > when I'm talking to journalists I just say "programmer" or something like that. > -- Linus Torvalds
On Thu, 22 Dec 2022 12:46:16 +0100 Andrzej Hajda <andrzej.hajda@intel.com> wrote: > Hi all, > > I hope there will be place for such tiny helper in kernel. > Quick cocci analyze shows there is probably few thousands places > where it could be useful. So to clarify, the intent here is a simple readability cleanup for existing open-coded exchange operations. The intent is *not* to identify existing xchg() sites which are unnecessarily atomic and to optimize them by using the non-atomic version. Have you considered the latter? > I am not sure who is good person to review/ack such patches, I can take 'em. > so I've used my intuition to construct to/cc lists, sorry for mistakes. > This is the 2nd approach of the same idea, with comments addressed[0]. > > The helper is tiny and there are advices we can leave without it, so > I want to present few arguments why it would be good to have it: > > 1. Code readability/simplification/number of lines: > > Real example from drivers/net/ethernet/mellanox/mlx5/core/esw/qos.c: > - previous_min_rate = evport->qos.min_rate; > - evport->qos.min_rate = min_rate; > + previous_min_rate = __xchg(evport->qos.min_rate, min_rate); > > For sure the code is more compact, and IMHO more readable. > > 2. Presence of similar helpers in other somehow related languages/libs: > > a) Rust[1]: 'replace' from std::mem module, there is also 'take' > helper (__xchg(&x, 0)), which is the same as private helper in > i915 - fetch_and_zero, see latest patch. > b) C++ [2]: 'exchange' from utility header. > > If the idea is OK there are still 2 qestions to answer: > > 1. Name of the helper, __xchg follows kernel conventions, > but for me Rust names are also OK. I like replace(), or, shockingly, exchange(). But... Can we simply make swap() return the previous value? previous_min_rate = swap(&evport->qos.min_rate, min_rate);
From: Andrew Morton <akpm@linux-foundation.org> Date: Thu, 22 Dec 2022 09:21:47 -0800 > On Thu, 22 Dec 2022 12:46:16 +0100 Andrzej Hajda <andrzej.hajda@intel.com> wrote: > > > Hi all, > > > > I hope there will be place for such tiny helper in kernel. > > Quick cocci analyze shows there is probably few thousands places > > where it could be useful. > > So to clarify, the intent here is a simple readability cleanup for > existing open-coded exchange operations. The intent is *not* to > identify existing xchg() sites which are unnecessarily atomic and to > optimize them by using the non-atomic version. > > Have you considered the latter? > > > I am not sure who is good person to review/ack such patches, > > I can take 'em. > > > so I've used my intuition to construct to/cc lists, sorry for mistakes. > > This is the 2nd approach of the same idea, with comments addressed[0]. > > > > The helper is tiny and there are advices we can leave without it, so > > I want to present few arguments why it would be good to have it: > > > > 1. Code readability/simplification/number of lines: > > > > Real example from drivers/net/ethernet/mellanox/mlx5/core/esw/qos.c: > > - previous_min_rate = evport->qos.min_rate; > > - evport->qos.min_rate = min_rate; > > + previous_min_rate = __xchg(evport->qos.min_rate, min_rate); > > > > For sure the code is more compact, and IMHO more readable. > > > > 2. Presence of similar helpers in other somehow related languages/libs: > > > > a) Rust[1]: 'replace' from std::mem module, there is also 'take' > > helper (__xchg(&x, 0)), which is the same as private helper in > > i915 - fetch_and_zero, see latest patch. > > b) C++ [2]: 'exchange' from utility header. > > > > If the idea is OK there are still 2 qestions to answer: > > > > 1. Name of the helper, __xchg follows kernel conventions, > > but for me Rust names are also OK. > > I like replace(), or, shockingly, exchange(). > > But... Can we simply make swap() return the previous value? > > previous_min_rate = swap(&evport->qos.min_rate, min_rate); Unforunately, swap()'s arguments get passed by names, not as pointers, so you can't do swap(some_ptr, NULL); -- pretty common pattern for xchg. Thanks, Olek
Forgive me late response - Holidays, On 22.12.2022 18:21, Andrew Morton wrote: > On Thu, 22 Dec 2022 12:46:16 +0100 Andrzej Hajda <andrzej.hajda@intel.com> wrote: > >> Hi all, >> >> I hope there will be place for such tiny helper in kernel. >> Quick cocci analyze shows there is probably few thousands places >> where it could be useful. > So to clarify, the intent here is a simple readability cleanup for > existing open-coded exchange operations. And replace private helpers with common one, see the last patch - the ultimate goal would be to replace all occurrences of fetch_and_zero with __xchg. > The intent is *not* to > identify existing xchg() sites which are unnecessarily atomic and to > optimize them by using the non-atomic version. > > Have you considered the latter? If you mean some way of (semi-)automatic detection of such cases, then no. Anyway this could be quite interesting challenge. > >> I am not sure who is good person to review/ack such patches, > I can take 'em. > >> so I've used my intuition to construct to/cc lists, sorry for mistakes. >> This is the 2nd approach of the same idea, with comments addressed[0]. >> >> The helper is tiny and there are advices we can leave without it, so >> I want to present few arguments why it would be good to have it: >> >> 1. Code readability/simplification/number of lines: >> >> Real example from drivers/net/ethernet/mellanox/mlx5/core/esw/qos.c: >> - previous_min_rate = evport->qos.min_rate; >> - evport->qos.min_rate = min_rate; >> + previous_min_rate = __xchg(evport->qos.min_rate, min_rate); >> >> For sure the code is more compact, and IMHO more readable. >> >> 2. Presence of similar helpers in other somehow related languages/libs: >> >> a) Rust[1]: 'replace' from std::mem module, there is also 'take' >> helper (__xchg(&x, 0)), which is the same as private helper in >> i915 - fetch_and_zero, see latest patch. >> b) C++ [2]: 'exchange' from utility header. >> >> If the idea is OK there are still 2 qestions to answer: >> >> 1. Name of the helper, __xchg follows kernel conventions, >> but for me Rust names are also OK. > I like replace(), or, shockingly, exchange(). > > But... Can we simply make swap() return the previous value? > > previous_min_rate = swap(&evport->qos.min_rate, min_rate); As Alexander already pointed out, swap requires 'references' to two variables, in contrast to xchg which requires reference to variable and value. So we cannot use swap for cases: old_value = __xchg(&x, new_value); Regards Andrzej
On Thu, Dec 29, 2022 at 10:54:50AM +0100, Andrzej Hajda wrote: > Forgive me late response - Holidays, > > On 22.12.2022 18:21, Andrew Morton wrote: > > On Thu, 22 Dec 2022 12:46:16 +0100 Andrzej Hajda <andrzej.hajda@intel.com> wrote: > > > > > Hi all, > > > > > > I hope there will be place for such tiny helper in kernel. > > > Quick cocci analyze shows there is probably few thousands places > > > where it could be useful. > > So to clarify, the intent here is a simple readability cleanup for > > existing open-coded exchange operations. > > And replace private helpers with common one, see the last patch - the > ultimate goal > would be to replace all occurrences of fetch_and_zero with __xchg. > > > The intent is *not* to > > identify existing xchg() sites which are unnecessarily atomic and to > > optimize them by using the non-atomic version. > > > > Have you considered the latter? > > If you mean some way of (semi-)automatic detection of such cases, then no. > Anyway this could be quite interesting challenge. My take is that unless there is very clear demand for this macro from outside of i915, it's not worth it. All that fetch_and_zero zero achieved is make i915 code a lot more confusing to read for people who don't know this thing. And it replaces 2 entirely standard lines of 0, every often clearing pointers in data structures where you really want the verbosity to have a reminder and thinking about the locking. Plus it smells way too much like the cmpxchg family of atomic functions, addig further to the locking confuion. Imo the right approach is to just open code this macro in i915 and then drop it. Again, unless enough people outside of i915 really really want this, and want to lift this to a kernel idiom. -Daniel > > > > > > I am not sure who is good person to review/ack such patches, > > I can take 'em. > > > > > so I've used my intuition to construct to/cc lists, sorry for mistakes. > > > This is the 2nd approach of the same idea, with comments addressed[0]. > > > > > > The helper is tiny and there are advices we can leave without it, so > > > I want to present few arguments why it would be good to have it: > > > > > > 1. Code readability/simplification/number of lines: > > > > > > Real example from drivers/net/ethernet/mellanox/mlx5/core/esw/qos.c: > > > - previous_min_rate = evport->qos.min_rate; > > > - evport->qos.min_rate = min_rate; > > > + previous_min_rate = __xchg(evport->qos.min_rate, min_rate); > > > > > > For sure the code is more compact, and IMHO more readable. > > > > > > 2. Presence of similar helpers in other somehow related languages/libs: > > > > > > a) Rust[1]: 'replace' from std::mem module, there is also 'take' > > > helper (__xchg(&x, 0)), which is the same as private helper in > > > i915 - fetch_and_zero, see latest patch. > > > b) C++ [2]: 'exchange' from utility header. > > > > > > If the idea is OK there are still 2 qestions to answer: > > > > > > 1. Name of the helper, __xchg follows kernel conventions, > > > but for me Rust names are also OK. > > I like replace(), or, shockingly, exchange(). > > > > But... Can we simply make swap() return the previous value? > > > > previous_min_rate = swap(&evport->qos.min_rate, min_rate); > > As Alexander already pointed out, swap requires 'references' to two > variables, > in contrast to xchg which requires reference to variable and value. > So we cannot use swap for cases: > old_value = __xchg(&x, new_value); > > Regards > Andrzej >