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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 08BEEC4332F for ; Thu, 29 Dec 2022 13:37:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 58D008E0002; Thu, 29 Dec 2022 08:37:01 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4E7B38E0001; Thu, 29 Dec 2022 08:37:01 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2C56E8E0002; Thu, 29 Dec 2022 08:37:01 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 16F198E0001 for ; Thu, 29 Dec 2022 08:37:01 -0500 (EST) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id C93F01A01A5 for ; Thu, 29 Dec 2022 13:37:00 +0000 (UTC) X-FDA: 80295444600.18.2064D11 Received: from new2-smtp.messagingengine.com (new2-smtp.messagingengine.com [66.111.4.224]) by imf12.hostedemail.com (Postfix) with ESMTP id 9F3A040004 for ; Thu, 29 Dec 2022 13:36:58 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=arndb.de header.s=fm1 header.b=nLBnuo5M; dkim=pass header.d=messagingengine.com header.s=fm2 header.b=Jr7RZJ44; spf=pass (imf12.hostedemail.com: domain of arnd@arndb.de designates 66.111.4.224 as permitted sender) smtp.mailfrom=arnd@arndb.de; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1672321019; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=lvF0202SLOTzT8hbWZsF0xJL4uK7PlwT0Y7oJgXZa8M=; b=hiV+G7hMirUCbOC6xGW3BpwuHTWrgNn0bmTRyg5s7yHWOOdGzQzYqAY/eLkmjruzbxjzKf f3NWzbCQ/KxiSCLVrCW4vUzvb1FjK61NzuOUf4h7AU/s3x66vQQt59YKEhpDRUvBgSnBlb KVeSZStmkmVdsTGXbkgOaeooJFOn1rE= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=arndb.de header.s=fm1 header.b=nLBnuo5M; dkim=pass header.d=messagingengine.com header.s=fm2 header.b=Jr7RZJ44; spf=pass (imf12.hostedemail.com: domain of arnd@arndb.de designates 66.111.4.224 as permitted sender) smtp.mailfrom=arnd@arndb.de; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1672321019; a=rsa-sha256; cv=none; b=VBSoG0Ysb3jf/6TpJWOR2lCzpk+syA/K904s0pwavqV5DBMkR2VPPlzSpzkaiKuncnuUlL oAiIMGlG08yyWM9dNqdL2CLeoZTxacBvyAorV2a13hZuCyixVuaGKifUT+VyS1Y8Kt5uCi k0MMMX4zUfhkuxsah+0iItmxqtmc/hM= Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailnew.nyi.internal (Postfix) with ESMTP id D47B95818EC; Thu, 29 Dec 2022 08:36:54 -0500 (EST) Received: from imap51 ([10.202.2.101]) by compute6.internal (MEProxy); Thu, 29 Dec 2022 08:36:54 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arndb.de; h=cc :cc:content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm1; t=1672321014; x=1672328214; bh=lvF0202SLO TzT8hbWZsF0xJL4uK7PlwT0Y7oJgXZa8M=; b=nLBnuo5MB8ib40z9s0xLWilN6X /WXV1Zqm3SxWb/ruB/kuFnhd7wdVmFZDNY+gYekuqiDs/3zSKTYpDCWeSGomp00d RPXAAm15lH7k/HckP7H41S1nTIssGFqnGEUCiAueXZhfqHbgvsgt2V/PjS5+24eK AZrmaFdvUCvnyYqeGiXNjFNJi0Nt+kY19b5QAViPegESXxc5lkw5/x38rzXBkE3E iMI/LuxJaJhu/PzxHG/w2bIL1OevR4DRQqXzZhgnnNrL6JlGZ2hfawrGtcjmfT5j 4NFrf2y4B2F4odzFC/4UEfyR9o8m6Tb2OX8h3xaP+cQbWCLPHyzz+PMCgWqQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1672321014; x=1672328214; bh=lvF0202SLOTzT8hbWZsF0xJL4uK7 PlwT0Y7oJgXZa8M=; b=Jr7RZJ443Rh8Qo+omI31KtzhJxzRr/gmnxzyHbaByHQ4 STqt+Vc4cv+k0j8Dn73jUOrcx91eQtuXMzjq9aHKcghW7M7CCsGYLd01CHiSCaAJ imgUtF7DvNdZzdYbFAKU118qzhWZ45FFNkuq01JO3G44O8dNsNM026hoPloISUUK uLAuPol2cYeE+H6rlz4SUHqOMhoDdaT6jlH1aTcg49YvTbDlhhD5kYpLI5s8bJxE VEdpvdUeBr2HOtE5jiNe1JbI9qe+BqGW8ENvyet3ESOPsDs6y7wveuue+TeGQ6OF 63+RmCQO5AYjeEdbwbZySMWQsDDFqh1CfW/rw6fbgQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrieeggdehgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvvefutgesthdtredtreertdenucfhrhhomhepfdetrhhn ugcuuegvrhhgmhgrnhhnfdcuoegrrhhnugesrghrnhgusgdruggvqeenucggtffrrghtth gvrhhnpeffheeugeetiefhgeethfejgfdtuefggeejleehjeeutefhfeeggefhkedtkeet ffenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrrh hnugesrghrnhgusgdruggv X-ME-Proxy: Feedback-ID: i56a14606:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 640B9B60086; Thu, 29 Dec 2022 08:36:52 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.7.0-alpha0-1185-g841157300a-fm-20221208.002-g84115730 Mime-Version: 1.0 Message-Id: <1d88ba9f-5541-4b67-9cc8-a361eef36547@app.fastmail.com> In-Reply-To: <20221219154119.286760562@infradead.org> References: <20221219153525.632521981@infradead.org> <20221219154119.286760562@infradead.org> Date: Thu, 29 Dec 2022 14:36:32 +0100 From: "Arnd Bergmann" To: "Peter Zijlstra" , "Linus Torvalds" Cc: "Jonathan Corbet" , "Will Deacon" , "Boqun Feng" , "Mark Rutland" , "Catalin Marinas" , dennis@kernel.org, "Tejun Heo" , "Christoph Lameter" , hca@linux.ibm.com, gor@linux.ibm.com, "Alexander Gordeev" , borntraeger@linux.ibm.com, svens@linux.ibm.com, "Herbert Xu" , "David S . Miller" , "Thomas Gleixner" , "Ingo Molnar" , "Borislav Petkov" , "Dave Hansen" , x86@kernel.org, "H. Peter Anvin" , joro@8bytes.org, suravee.suthikulpanit@amd.com, "Robin Murphy" , dwmw2@infradead.org, baolu.lu@linux.intel.com, "Pekka Enberg" , "David Rientjes" , "Joonsoo Kim" , "Andrew Morton" , "Vlastimil Babka" , "Roman Gushchin" , "Hyeonggon Yoo" <42.hyeyoo@gmail.com>, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-s390@vger.kernel.org, linux-crypto@vger.kernel.org, iommu@lists.linux.dev, Linux-Arch Subject: Re: [RFC][PATCH 07/12] percpu: Wire up cmpxchg128 Content-Type: text/plain X-Stat-Signature: 1mkdg5xaw5jze53a7453r9p7rk9tpd5t X-Rspam-User: X-Rspamd-Queue-Id: 9F3A040004 X-Rspamd-Server: rspam06 X-HE-Tag: 1672321018-961008 X-HE-Meta: U2FsdGVkX19qoxhr8dT0FKBjBamJOI2n1v4mOOcrY16pLsQ7bTUT7vUTcAMBEU1M3Oux8wyVJ5dQj0wOojr3WxLNAMTOpbDoz8d38T+xcmaCVlPvGMQUtyIekzov6LZSwiVipjDLvmEKmB/JnxBrqi4b0TtdX7ygN2eah3Lm7ZUpCkl/WTLYVJuXx+rD0pcP1oVXxUKZxz+Vzv4M1rvdMZi1PLMj0eJTTZlbGMJHPXosU7oe6hhFk/vEhFtMsLFKkGATGSi+Ig4unUAgMZDrCR/SKWOVs5PE9L4tGIJhR89V4GEgNAmt93ZrTi9jklSpYv8lelkzjDUD3Q/6gA5vu/cESY43BwUyEfLJWwEs9xLYfui07i0JYwVJcJE0zp0pmek8pJ/5IX2M14ZbN/UNE3WkzNIjyBJpwN5VnRdv6zPs/ucFsRbRfOaGc8P7y7G6iMnTKsHOc69kZQyabCvvuH0fXSxsnd48/stBIbsPpnE9448Xi68ccrcWYNwCQuuzLIjGv30VNQA3NVEIfuN+ALaIIKocJ0jvXlgaSbifu9D3tbQxEvu1kMY7UVcXDcbo8RIxi6ELS8566E1Y8B1cHCCOaLnkjmr86OVpUsVAYh8oJ6gZbDAphjSFNp3gm9MjdtsLrL7J+DIjkgFt3SJL+fwDoow75uaMAKA7apjSrdOvO/r0hHgUHdofYt8dO1WV61ewGj1mUKADU2VQopzI4TD+1xfZmVZ8mtpa2/+Nzr1LhgoNQC6xdxOApaPIkF5A7Yj8r7pClUJSxG9F0Y8/frxjE3B1J370uL02HnjJ1gEWXROJdAmBLkLU/pj1leQ8Z3dNaNhsUEppIZ1BAi4MFgQ5mazweFkZ3e06FX01i1X4lSfZhc5RS/VJBL7mv/oPgUDFMQhki3mtFDda42kExZN3EveE/MrA3foVjJF48qUBxS8DnPKP5vc/LUTGMvhzccxzJW8qWlfiGp+zLma b/xgLb0z YtRz43gQ1nEVZSLM= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, Dec 19, 2022, at 16:35, Peter Zijlstra wrote: > In order to replace cmpxchg_double() with the newly minted > cmpxchg128() family of functions, wire it up in this_cpu_cmpxchg(). > > Signed-off-by: Peter Zijlstra (Intel) Does this work on x86 chips without X86_FEATURE_CX16? As far as I can tell, the new percpu_cmpxchg128_op uses the cmpxchg16b instruction unconditionally without checking for the feature bit first, and is now used by this_cpu_cmpxchg() unconditionally as well. This is fine for the moment if the only user is mm/slub.c and that retains the system_has_cmpxchg128() runtime check, but I think a better interface would be to guarantee that this_cpu_cmpxchg() always ends up either in a working inline asm or the generic fallback but not an invalid opcode. For consistency, I would also suggest this_cpu_cmpxchg() to take the same argument types as cmpxchg(): at most 'unsigned long' sized, with additional this_cpu_cmpxchg64() and this_cpu_cmpxchg128() macros that take fixed-size arguments. I have an older patch set that additionally converts all 8-bit and 16-bit cmpxchg()/xchg() calls to cmpxchg_8()/ xchg_8()/cmpxchg_16()/xchg_16() and and leaves only the fixed-32bit and variable typed 'unsigned long' sized callers for the weakly typed variant. Arnd