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 AA0FBC05027 for ; Mon, 6 Feb 2023 12:14:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0926E6B0072; Mon, 6 Feb 2023 07:14:54 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 042A76B0073; Mon, 6 Feb 2023 07:14:53 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E26076B0074; Mon, 6 Feb 2023 07:14:53 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id D3B276B0072 for ; Mon, 6 Feb 2023 07:14:53 -0500 (EST) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id A17091A0E05 for ; Mon, 6 Feb 2023 12:14:53 +0000 (UTC) X-FDA: 80436760866.21.44D5CF8 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf15.hostedemail.com (Postfix) with ESMTP id 32ADCA0018 for ; Mon, 6 Feb 2023 12:14:50 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=ntuP4M7d; spf=none (imf15.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=1675685692; 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=RSckQc2Emh9jJfvS33gHYGvM8sjY/00hI0zuLioFFNM=; b=lwqaZji4O9IxvgHbP6W1N5sWmgWu11DgWbRv8CQb1hhkiZUjn2ix2bdHdTVEvwUCtp9eXm 6AspLT0kl/yB8O90WD4sxRfGwowTyr0dBovejJnH3RakCJBta1NmTWxLZKaLTyyrPTGIPj soUguBUknK+bR51gMETHnwSXZvT8oso= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=ntuP4M7d; spf=none (imf15.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=1675685692; a=rsa-sha256; cv=none; b=g4nBXN4Pyq4kZZxi3nhGz8PoQwg+mSTb2TaVLx8Tr/18yCMWpTDreKuslQjAE2SIdqD5NX drkDUUvZ769yEVjnFKci6ORFeJPtcBzEiyhmamqoA3QaTvx+O4bS6wDfZKwJvMext09glQ lCX2rXquvrM6orBoKJLBU7R8uMAsrt8= 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=RSckQc2Emh9jJfvS33gHYGvM8sjY/00hI0zuLioFFNM=; b=ntuP4M7dSK2zsWVQTbDs9Ox2Ac V4r4EFjkZ99kyYLqdozZ6xzE+QxqYHoG0WCIaMJeVBoR6Y2BbtLPsYb3i01D2x0modrsfxSX57f8v DF30B1tNGD0ZtMzW6GNbWnE/bcmDfjWi9O6PWHEH/Si4SWWexelyntk5L1wIG2NbBH0WlqmGoT5WP AyMxq8eNX+N/jJLzOfoUuQe06/8Jp7hZdjmobg06aJY4TkJlY21aHVxYTE2KfbswHeSGde/+OdjK2 Dlior1hUsskbO4lX904cgjfDDm8i9Mg06fGrnhOO3gfkmEmyQ166CbjhPt5EUYYdvgrPaRfUt5YvB rcxZk8pQ==; 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 1pP0OE-00GkH1-Ik; Mon, 06 Feb 2023 12:14:31 +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 6EA2030030F; Mon, 6 Feb 2023 13:14:28 +0100 (CET) Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 084DE207A0B88; Mon, 6 Feb 2023 13:14:27 +0100 (CET) Date: Mon, 6 Feb 2023 13:14:27 +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: X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 32ADCA0018 X-Rspam-User: X-Stat-Signature: umw76kyqx9brfn945fatecad6so3rj73 X-HE-Tag: 1675685690-203649 X-HE-Meta: U2FsdGVkX1/fXGA0p55gbCiuxEYcc9NRa0BNkxNq7zfxSnLtK2GJwaJ9HLlgGPr0AzknND199i9S4smptAd9/zFRIwk3Iv8aKSeKX0dvAzWC+BzvtNtbZXMnqVyrs6ER9lW+qcQGhcy13FC7jPppD0AonlNmc1H5dhjDJeOHRws6kp2v7OYPCfKW1M9Ei3Dm1e7kbLVzfy5DhzklsuyNCojp0xH/OUdQyvcISaHFI+OtO06zkLPJknx852G8DoHobNpRpMoZv/mD09g9QS7Wo9CaYjk2cDSUCwJf4TGM8XKZPYk0qKUUAUQFZCkkCW/FyT8IfW4T9qu2PJ4+VvDBc0Nrb2DcJybkIkyUR6x9K1GT4omKBuHJQhLrcSFSLXx4a3a2Ob7DrZ+zbGJQ9eYSZUBa8PhB1g/ZtfpASu52MTrx14SeZzWrJ3bAweij4mpDmQatoL1R1uKS5DZJ9deLqv05CsjoiPUo3u6HWvOo5KYwOH/jL8csuyu3Z2Q2mSTUiBZkw+iIEqKhl2GPlwKeHN6eF+rViiFzqEZlKMSCPjpOp/69ZlOe6SOE2y7zNKXo92gXAddjasvGeP9IJvoptTan+0oZveDfaPYH5lCPXRRfclt81tjWjNT4G1kEi2kXdWcDwO6+NsznW4ropuW3upssapU6n+fOlFrZqrhYv7AbPJO70kpziOj6XJxTRAv9OjV8S7BAe2tetOT4c2fwDqL5PMk5qt0uaJmqhTmp0RwN46dBI7D+xTTD0lthrNS9nvcE7R99YnJXaNulatjmqw0cP+kntywqSBmZSlajDcDEVxnexyDy6QXGlmAFsi2VJ1VAk8W0X98MlWJspSIPgZyUJKd6Adbhu/koPXVkNJ+vseClPMfN4yKg3s825Wkyk7jDUZEXbK+ja9BSgLyFpwzT4FEReN7OSjpMPZLmmL2QGZP+jCKo2ZzH6GvJLOrQvEbvbWrVeY4n5WIc9ip UU0dYXGg Bemk2qAUpr7a+HIOKkZt7gqCLPWMCS3Gv/oNuaP0EHU2aVutzLsXJegS0JBnZ7ZMeRPblPPyh8AVAlk1C8kdBCRhpD4L41O6hnFDURAZuDtAKIhXQN/2HL8O3RVHsZSK2BOWfkyDj6ehacdwMKOPxAHU6m/F/MOkn2mNGWo2iAxGcKpMlb5vz7D2LRrXeq2+Hvcjghr9ddc/h4r7x3O7tO2hoX0s5suUQ31bQ 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, Feb 06, 2023 at 12:24:00PM +0100, Peter Zijlstra wrote: > > 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. So lookng at this I remember why I did it like this, currently 32bit archs silently fall back to the generics for most/all 64bit ops. And personally I would just as soon drop support for the !X86_FEATURE_CX* cpus... :/ Those are some serious museum pieces. One problem with silent downgrades like this is that semantics vs NMI change, which makes for subtle bugs on said museum pieces. Basically, using 64bit percpu ops on 32bit is already somewhat dangerous -- wiring up native cmpxchg64 support in that case seemed an improvement. Anyway... let me get on with doing explicit {raw,this}_cpu_cmpxchg{64,128}() thingies.