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 943EFC05027 for ; Mon, 6 Feb 2023 11:24:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2661E6B0072; Mon, 6 Feb 2023 06:24:35 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2168F6B0073; Mon, 6 Feb 2023 06:24:35 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0DDF16B0074; Mon, 6 Feb 2023 06:24:35 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id F29096B0072 for ; Mon, 6 Feb 2023 06:24:34 -0500 (EST) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id C32A21C6425 for ; Mon, 6 Feb 2023 11:24:34 +0000 (UTC) X-FDA: 80436634068.27.8821663 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf13.hostedemail.com (Postfix) with ESMTP id 70F792000A for ; Mon, 6 Feb 2023 11:24:32 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=Ea7S5G84; spf=none (imf13.hostedemail.com: domain of peterz@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=peterz@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1675682673; 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=6p5UcUVJMB6FcC7LDxPnes2LOQaJUS8z6IEOS3X783s=; b=w8F70YVxGWz+NdlVrbNV6PYQISrdgCM0SFFg2UfnF0Z3YAqb1+Nocod9jS1XfktwIzGDco qxxYMoyT3C2tvuKX/jwhUbDwWgGBoAibD/njNHR0nnNLE4TGaDRAQfCxLhRn80htpTw/rW f/p6eUCmzK+2EWzUBQ2KNJD8iqb6rjI= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=Ea7S5G84; spf=none (imf13.hostedemail.com: domain of peterz@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=peterz@infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1675682673; a=rsa-sha256; cv=none; b=zdrijhPZCq8qymVJ2PaGuplEbtjHfWlNnimKOV79xYlo+SDtA6VKpjTNdS+NzBOjVX7JIP uGUR5A6ufnuvaSom2wopKjOWjXGWxnDG/mP9Rcq/c5IKYBSWz5tgtZj5VHZCyDRmi5+h5P HlFoe67QOiRaEoSi2pO+EGmQfsEtgtc= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=6p5UcUVJMB6FcC7LDxPnes2LOQaJUS8z6IEOS3X783s=; b=Ea7S5G84aDpNMvL/Suxi9XIvmP C3d8gqapGDHgOfKkaP3NfNlfpuswBdZ+/65aPGo8Ipfi4ygRk8xZ7E1lb+BYSVGzxaS2sN48Bj+uV 7EcpbhbKtu3+Vy6v0rx38wmRy2zhh9BHTpbWgMb6B1VUojynlRhGLZwyBBeJ97ZTbSyUL+nN/9cdA g3KAlOkdL6bK9I8Ru0c8Xd4so95LlWcA9jGTKHdvLf99ddC9qSvsG4IxnKgYDCF/ShOfXC3/ZQNuz +ltBvaSkLaaFq/cirv5PAA/Jvc9EmJp6O0MLa9hEeS1tkPMdnYzaGXwcTfJ4KZOOty5sepN3i9T7J b/03MOXw==; Received: from j130084.upc-j.chello.nl ([24.132.130.84] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.94.2 #2 (Red Hat Linux)) id 1pOzbS-00Gi9E-Dh; Mon, 06 Feb 2023 11:24:06 +0000 Received: from hirez.programming.kicks-ass.net (hirez.programming.kicks-ass.net [192.168.1.225]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id C110E30013F; Mon, 6 Feb 2023 12:24:00 +0100 (CET) Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 8C4252CFF4E16; Mon, 6 Feb 2023 12:24:00 +0100 (CET) Date: Mon, 6 Feb 2023 12:24:00 +0100 From: Peter Zijlstra To: Arnd Bergmann Cc: Linus Torvalds , Jonathan Corbet , Will Deacon , Boqun Feng , Mark Rutland , Catalin Marinas , dennis@kernel.org, Tejun Heo , Christoph Lameter , Heiko Carstens , gor@linux.ibm.com, Alexander Gordeev , borntraeger@linux.ibm.com, Sven Schnelle , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Joerg Roedel , suravee.suthikulpanit@amd.com, Robin Murphy , dwmw2@infradead.org, Baolu Lu , Herbert Xu , "David S . Miller" , 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, iommu@lists.linux.dev, Linux-Arch , linux-crypto@vger.kernel.org Subject: Re: [PATCH v2 05/10] percpu: Wire up cmpxchg128 Message-ID: References: <20230202145030.223740842@infradead.org> <20230202152655.494373332@infradead.org> <24007667-1ff3-4c86-9c17-a361c3f9f072@app.fastmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <24007667-1ff3-4c86-9c17-a361c3f9f072@app.fastmail.com> X-Rspamd-Queue-Id: 70F792000A X-Stat-Signature: 9tsgqme61o3n1hsdku1pnginjeh7dfnq X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1675682672-311142 X-HE-Meta: U2FsdGVkX196qxKLy6WSoSKOYnVTpqI5a3KMi3nBz2EK7Ar7w2cQBtOnvpsdJ6aWZkXcFEMYZFveCfgcGsFpJ83ZroCPLTnMreSRyKRtRVnSqI5Bjy5+WLcvwKEek5g5ObWh+0/vPOKsrwxQ+HIV3/1rS7GidwFqT/SGR13W+j0Wz3IZwPJ7VAB46pisUFCPh9X6E7/G/TOXjPJV7UuXdwZhOR81w/qUXIJtYHmOUjlT7oIZFgfy2hdZpp78YckpFLI6vUbkccaF7N+nm/ul5WBgzaV0azK1GuDgTwsyIJS+PzRJIdOqRyvO/nsQhIstRU0j7sQS2nubB4S6sKUzXZyT+UBAsqDEpkExV/MAXvuIPJ9WOOq4WLR54/VPAvrF7TMbR0ozaBe+HNF/nGwAdfJy/d8a3UPz8aJkNNAoEyHs6GuOabgqkSLNSQ2CLF8afmrzr5NjocNjyq1uh/cPKyQEho5jEt3WCORq2yGieb1jkbEugC1B1CPzob/7CqvBpIRHoH5K/gc4FFuj+DcHQZXTKpvEP8z/x38lo/FlDp8yBIInck81Mwfn9YFGtrBxlfGES83EHEZGSbhzebelzgP5sgRWNW9S1Q9Okgcrvw68YXasOiLSPU/0WzDzY9hNEhOA7QpouOxysEP4pbrJ1iltmiErwnkwjVMcELG6wDGqmOXmC8PJcm8qo4o2cpd37vt2isdKGjPwE0xQOAV22Zk0YGJY7C2VkHl72BeY2JDemL2ahGlggN59qC3fhhcgH6AwBrW5wsut/vWBytflbRQEl8FtTBRNdtxsE8hIfZGx/9WnvM6Rt0OqFHs3mMTlKiJlOehut19tIWxlWfUX2p62dIUqwclMnf/N3UX+9QIrJsJ+aa5DFkXm4+N0b4h6xXS4eLJGGRPK/AK2r9vdIpzN8WW0MCdYQGKZ79Ho+f9IKtV72V7JkzpIWdqyCOUgCvbaOBxY+qT/Ebp97p2 i8PYmwx1 clv/mcZJDZAePcS7mFiNhiZ6T/zUGhCCOliYGFgbQg5StkbOP2stuz0t5fx5Y1MlC9yuUGRmceIshkPyt4Guaoa5Vghfyx8FRViZF3niLgsyaTojx7KleNmyGdr+FuopWvcrWSNypUgX9nvyYCaM0daKvT+e42bprLHq7Cqp826OdomOKILVibAgVLAd2lvD6HQHBDfttUVS2+XUZj4S9L87dxmXn0r7OfoGEtWk9vjKI0CQAOGcn96VpKGwYy18fHz0QhynvkfAQ6WpsnEUCUpRwqWmJ3miBHpmQTtsZroeveNkt8hpHM9hMgVX/jHdCxgznC9fMCFnR8X7FtqfIfsqSm41wY9PSUKuktwfDQRlG2CbSy/FUKZPVQ+brHJKt/JxuOeiXwGkeruHLBC/oXULkcfATtNBrHZsVlz2XY4Y9gC4= 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 Fri, Feb 03, 2023 at 06:25:04PM +0100, Arnd Bergmann wrote: > On Thu, Feb 2, 2023, at 15:50, 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) > > I commented on this in the previous version but never got any > reply from you: > > https://lore.kernel.org/all/1d88ba9f-5541-4b67-9cc8-a361eef36547@app.fastmail.com/ Sorry, seem to have missed that :/ > Unless I have misunderstood what you are doing, my concerns are > still the same: > > > #define this_cpu_cmpxchg(pcp, oval, nval) \ > > - __pcpu_size_call_return2(this_cpu_cmpxchg_, pcp, oval, nval) > > + __pcpu_size16_call_return2(this_cpu_cmpxchg_, pcp, oval, nval) > > #define this_cpu_cmpxchg_double(pcp1, pcp2, oval1, oval2, nval1, > > nval2) \ > > __pcpu_double_call_return_bool(this_cpu_cmpxchg_double_, pcp1, pcp2, > > oval1, oval2, nval1, nval2) > > Having a variable-length this_cpu_cmpxchg() that turns into cmpxchg128() > and cmpxchg64() even on CPUs where this traps (!X86_FEATURE_CX16) seems > like a bad design to me. > > I would much prefer fixed-length this_cpu_cmpxchg64()/this_cpu_cmpxchg128() > calls that never trap but fall back to the generic version on CPUs that > are lacking the atomics. You're thinking acidental usage etc..? Lemme see what I can do.