Message ID | 20230925150905.54842-2-ubizjak@gmail.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:cae8:0:b0:403:3b70:6f57 with SMTP id r8csp1335665vqu; Mon, 25 Sep 2023 09:29:24 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFwbr/mRkvlIiTmdamEMwk/8VwDOz2DpGRFulKrPqSda+qk0nr5g39eXm5hddVjRMZ57z0F X-Received: by 2002:a17:903:4345:b0:1c6:2b3d:d918 with SMTP id lo5-20020a170903434500b001c62b3dd918mr528476plb.3.1695659364155; Mon, 25 Sep 2023 09:29:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1695659364; cv=none; d=google.com; s=arc-20160816; b=Hy/xAh4L0RI6J2p2EC1jdh6/FtdztTz+ybO48GRLkDbrmDJX0REDSXCimt6tkh/d7b 3CIKvolwcuBg4AGMdf5QTPXu1VzXK9BsV83xRjc4ofTe5MR8V4O2ivM8WJKv2XIbawVF n0CGM+XVYF85XsCo2EqUhTTyYi9O0hQgvdgHNyAL/S4gC+x7/vrKQ1YEhbx16mKc0yzh y2+fKJylztt7V27mjGchQ0Bi900Yec82AYiaqcBwOcRRqIYjeB5r8Jp8+VspciXXqLXa gTc3AFcVJXE/vs2C3dto3BvwhxNQF+z+Mqfjpx4ybv5M3Vi0/hA43BpXVKjUGQi9S5Y0 YrYg== 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=eC20xI+X56Gh8DNv6Zud5IHxjD2gnnvulA3kJH1zjMo=; fh=oYLmOjdVRcynsGxj/woJDJFI3cX4I+zd8Zp2czk4tCE=; b=cz7WcPCLDJZvNqIGJvMX1F0p3nJ60NMhNRv/7f3tB8M9WxR5fa6Y74t0cxBMQbsajl AQkY7uLwgJ05K66WM5MS6cCcm2/LFmNAzcPLURmSo+cRu/kzZdQD+/5iIKkdRf6Q5quN B76pHZkfAxKJxSeouGuj8Us6+v8BlB//pxeXBR961HL1NE+BtOlEv6GYfvOi2rD+NRmD PLuoTJE1HV82hyljG9K4Rcfz0kMheqxsMh8Vdn1bOEe0QnrFCx23+1golOyfbipL9Vym EaRxL/oTZCC3YrL0XUI/X7uNx92KPLzsoJspnAw1EjSZwA1u5j7we58lCRHOh93ipo1Z Zlyg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=V7um3RNH; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from snail.vger.email (snail.vger.email. [23.128.96.37]) by mx.google.com with ESMTPS id f1-20020a170902684100b001bf1d1d99f6si10564792pln.358.2023.09.25.09.29.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 25 Sep 2023 09:29:24 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) client-ip=23.128.96.37; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=V7um3RNH; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by snail.vger.email (Postfix) with ESMTP id D917180AEB02; Mon, 25 Sep 2023 08:10:06 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at snail.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232134AbjIYPKD (ORCPT <rfc822;pusanteemu@gmail.com> + 29 others); Mon, 25 Sep 2023 11:10:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50546 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231263AbjIYPKB (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 25 Sep 2023 11:10:01 -0400 Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 90A46103 for <linux-kernel@vger.kernel.org>; Mon, 25 Sep 2023 08:09:55 -0700 (PDT) Received: by mail-ej1-x629.google.com with SMTP id a640c23a62f3a-9b0168a9e05so578748366b.3 for <linux-kernel@vger.kernel.org>; Mon, 25 Sep 2023 08:09:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695654594; x=1696259394; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=eC20xI+X56Gh8DNv6Zud5IHxjD2gnnvulA3kJH1zjMo=; b=V7um3RNHEMlI2ENEsAM54gm8G28JaVKxoFXWP6yCulk6LnB4NycUE+5/qnn6ySKLgo Uo0tuBTgMX3Tc4U9TIt0RKHeSJgG8drrpq96DeKS52GNqZgx21u5xULvz7bzgZ99xNYt a1GKpuhasaMXQwwlLw8IoNe+Dd28rojetOlUID14Jk0TbWNabA3Wl9kmFmdadQG6jnm2 Xri7LihKtPh3hpvy5TkvyQzpLsFlqCpXqGx3XzSZdyWI5wNefS3kdYbqbLqEFy/ARkpi Fn97pN83ikW3j2Yrjx+sD8Jk9i9ZNfv/B/vNxslCrDrkTWrJI5ycmssPcipvGlYvyR5J KgIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695654594; x=1696259394; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=eC20xI+X56Gh8DNv6Zud5IHxjD2gnnvulA3kJH1zjMo=; b=I/MjlfyiMIwMYQcCrDG/E55g4HnxC9FRxp+9jegFaWJ1eac/YlGd43ecd51rYt4kQD If4GkdszALM4TLYgLit2NJtnEhLuguocjukXCCtdzQI2VJ3FBkOkW6lFYE/wCf1Wg0my T9WkYct25epaBbbGzlXd9IhAxu9nWkdB7/2YLTG6gHeyfK4NzETA2wyPhMNXh3mv/Gws 5SCx/+KG1mzN8qnGw1Bx4WS4bSCR1kGQfZGrXvx7HvF78NY5vuzViJvU1/xIFBHpzvyL ie0kRfvNVX64rDYcwbvKZ0+lQEJG1+6JOurGca4Csp1FSYFaD2jByfMUikowWxs3w5Dn Yh2w== X-Gm-Message-State: AOJu0YxOl08DKwqVuzhhArH38O80YaeS/PGmINtVTCaXxPBF1hd/bj4H B2Htgl9GzyG0E2bdm53YXKL+dHbV0Fb4FA== X-Received: by 2002:a17:906:9a:b0:9ae:56b5:619d with SMTP id 26-20020a170906009a00b009ae56b5619dmr6161137ejc.16.1695654593710; Mon, 25 Sep 2023 08:09:53 -0700 (PDT) Received: from localhost.localdomain ([46.248.82.114]) by smtp.gmail.com with ESMTPSA id i13-20020a1709061ccd00b00989828a42e8sm6442191ejh.154.2023.09.25.08.09.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 25 Sep 2023 08:09:53 -0700 (PDT) From: Uros Bizjak <ubizjak@gmail.com> To: x86@kernel.org, linux-kernel@vger.kernel.org Cc: Uros Bizjak <ubizjak@gmail.com>, Peter Zijlstra <peterz@infradead.org>, Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@kernel.org>, Borislav Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>, "H. Peter Anvin" <hpa@zytor.com> Subject: [RESEND PATCH 2/2] locking/x86: Wire up sync_try_cmpxchg Date: Mon, 25 Sep 2023 17:08:24 +0200 Message-ID: <20230925150905.54842-2-ubizjak@gmail.com> X-Mailer: git-send-email 2.41.0 In-Reply-To: <20230925150905.54842-1-ubizjak@gmail.com> References: <20230925150905.54842-1-ubizjak@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Mon, 25 Sep 2023 08:10:06 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1778027713327502421 X-GMAIL-MSGID: 1778027713327502421 |
Series |
[RESEND,1/2] locking/generic: Add generic support for sync_try_cmpxchg and its fallback
|
|
Commit Message
Uros Bizjak
Sept. 25, 2023, 3:08 p.m. UTC
Implement target specific support for sync_try_cmpxchg.
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Signed-off-by: Uros Bizjak <ubizjak@gmail.com>
---
arch/x86/include/asm/cmpxchg.h | 6 ++++++
1 file changed, 6 insertions(+)
Comments
* Uros Bizjak <ubizjak@gmail.com> wrote:
> Implement target specific support for sync_try_cmpxchg.
Could you please provide a before/after description of how
this improves things exactly?
Thanks,
Ingo
On Thu, Sep 28, 2023 at 10:53 PM Ingo Molnar <mingo@kernel.org> wrote: > > > * Uros Bizjak <ubizjak@gmail.com> wrote: > > > Implement target specific support for sync_try_cmpxchg. > > Could you please provide a before/after description of how > this improves things exactly? The improvement [1] was demonstrated in the original patch submission. The resent part of the patch series is an infrastructure part, which introduces a new locking primitive, together with its fallback, so it has to be committed first. The improvement is in the other part of the kernel, and this part requires the infrastructure part. To avoid unwanted patch dependencies, I propose to commit the infrastructure part first, and after that commit the XEN part of the series. (Please note that the XEN part is already acked by the maintainer). I will mention the concrete improvement (code simplification as shown in [1] and better generated assembly for x86 targets) in the formal submission of the XEN part. Please also note checksums in include/linux/atomic header files. It is necessary to regenerate the headers every time the checksum changes. The resend of the infrastructure part was thus necessary due to the recent fixes in this area. [1] https://lore.kernel.org/lkml/20230710192440.47140-3-ubizjak@gmail.com/ Thanks, Uros.
* Uros Bizjak <ubizjak@gmail.com> wrote: > On Thu, Sep 28, 2023 at 10:53 PM Ingo Molnar <mingo@kernel.org> wrote: > > > > > > * Uros Bizjak <ubizjak@gmail.com> wrote: > > > > > Implement target specific support for sync_try_cmpxchg. > > > > Could you please provide a before/after description of how > > this improves things exactly? > > The improvement [1] was demonstrated in the original patch submission. What I'm saying: please integrate the required context & arguments into the changelogs of the patches you submit. Patches that change code generation should demonstrate what they achieve. - If existing code changes, then describe/demonstrate it with disassembly. - If existing code generation is unchanged, then *declare that property in the changelog*, and mention that a future patch relies those changes. You can either include that future patch in this series, or you can describe/demonstrate the benefits in the changelog while noting that those changes will come in future patches. Your submission, as-is, provided no context whatsoever, it described only the 'how', not the 'why'. Thanks, Ingo
diff --git a/arch/x86/include/asm/cmpxchg.h b/arch/x86/include/asm/cmpxchg.h index d53636506134..5612648b0202 100644 --- a/arch/x86/include/asm/cmpxchg.h +++ b/arch/x86/include/asm/cmpxchg.h @@ -221,12 +221,18 @@ extern void __add_wrong_size(void) #define __try_cmpxchg(ptr, pold, new, size) \ __raw_try_cmpxchg((ptr), (pold), (new), (size), LOCK_PREFIX) +#define __sync_try_cmpxchg(ptr, pold, new, size) \ + __raw_try_cmpxchg((ptr), (pold), (new), (size), "lock; ") + #define __try_cmpxchg_local(ptr, pold, new, size) \ __raw_try_cmpxchg((ptr), (pold), (new), (size), "") #define arch_try_cmpxchg(ptr, pold, new) \ __try_cmpxchg((ptr), (pold), (new), sizeof(*(ptr))) +#define arch_sync_try_cmpxchg(ptr, pold, new) \ + __sync_try_cmpxchg((ptr), (pold), (new), sizeof(*(ptr))) + #define arch_try_cmpxchg_local(ptr, pold, new) \ __try_cmpxchg_local((ptr), (pold), (new), sizeof(*(ptr)))