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 X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4069EC11F65 for ; Wed, 30 Jun 2021 12:25:03 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1AD1861409 for ; Wed, 30 Jun 2021 12:25:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234507AbhF3M1a (ORCPT ); Wed, 30 Jun 2021 08:27:30 -0400 Received: from mout.kundenserver.de ([212.227.126.135]:48861 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234490AbhF3M13 (ORCPT ); Wed, 30 Jun 2021 08:27:29 -0400 Received: from mail-wr1-f43.google.com ([209.85.221.43]) by mrelayeu.kundenserver.de (mreue010 [213.165.67.97]) with ESMTPSA (Nemesis) id 1MwQGj-1l71Je22aL-00sJRe for ; Wed, 30 Jun 2021 14:24:59 +0200 Received: by mail-wr1-f43.google.com with SMTP id f14so3029817wrs.6 for ; Wed, 30 Jun 2021 05:24:59 -0700 (PDT) X-Gm-Message-State: AOAM533Rq0bjHjqeIxQOo98KvfC95Qugr1nlXU3FeWFiCvr/DU0BBY+A oDOEbMz+J3tEc6LTJwDWeDt48OuAWEpRjQCUEvc= X-Google-Smtp-Source: ABdhPJyvqh3j6mbSU1KmlUuXCp1yqw5wRXTQvgUnEwHAMGx9Ka3OvJMS9eU1Dt3llWzRAQtWzJWWQ6AaURHNtxTqlPY= X-Received: by 2002:adf:ee10:: with SMTP id y16mr1616263wrn.99.1625055899168; Wed, 30 Jun 2021 05:24:59 -0700 (PDT) MIME-Version: 1.0 References: <20210525140232.53872-1-mark.rutland@arm.com> <20210618084847.GA93984@C02TD0UTHF1T.local> <8a056e32-26bf-3038-984e-fcf8cac988d0@infradead.org> <4ec7308f-02c6-a357-eab8-63b6f2b7a5eb@infradead.org> In-Reply-To: From: Arnd Bergmann Date: Wed, 30 Jun 2021 14:24:43 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 00/33] locking/atomic: convert all architectures to ARCH_ATOMIC To: Peter Zijlstra Cc: Randy Dunlap , Mark Rutland , Linux Kernel Mailing List , Will Deacon , Boqun Feng , Albert Ou , Brian Cain , Benjamin Herrenschmidt , Chris Zankel , Rich Felker , David Miller , Vincent Chen , Helge Deller , Geert Uytterhoeven , Greg Ungerer , Greentime Hu , Guo Ren , Ivan Kokshaysky , James Bottomley , Max Filippov , Jonas Bonn , Ley Foon Tan , Russell King - ARM Linux , Matt Turner , Michal Simek , Michael Ellerman , Nick Hu , Palmer Dabbelt , Paul Mackerras , Paul Walmsley , Richard Henderson , Stafford Horne , Stefan Kristiansson , Thomas Bogendoerfer , Vineet Gupta , Yoshinori Sato Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:x3f8ffoy30Ku6ZSIoJuL4Zhum2LeiEmWqG0ehIUcWZsM9eI3kME nCJsHtKREfDcaOFh46SMNvgi1SsF2iFSbk/lkJBeLem6OBX14Dm1H05kPWeg5IQiaXo5WdF Ux3rLsaw2hcenjqn9WQ5vxXPrm7O0cRaLtMCRABcr7G8w54z6FWl4uSkhPdDuMnh+2T5ubS 5+SOnHG9gxO/WIVbmD+bw== X-UI-Out-Filterresults: notjunk:1;V03:K0:ZDiS7ZHrmys=:fdUjE6WUFnz5ta3aC6p3vg KSaAT0soQKQaMlo67hUbUfXmyZGghvVhvl5CHuxTAR+aaq+33a5Dn43bbZT3rDJLmOTuY4Qd+ vTM1j1GLaY7d7Ngbt7eXfbuntkglIcgbojufSoTzW7kyjAgn7Q8vgQOdp6orGTfgNuAyoNxGQ 420M0jMQkq8OgBoVebhMN0KkqXJeEnN7XTugya5SN16v7XQAnwwj14GdriHEfumNHvXjaM0WV KPGh5sOej0BDjhwjENK9lDRgYUnme8U1Y7/2eLcHVPSu11AobVkpdQV6AQavABB5bHQRC99fi de/3eUKxWGkL2JsrYKB0FHMm8QhULWtA3LJ79ztSrkjYSQ2grwDc3Jlc6ptlKHUi63bPgaKBw X3pWk7rX0tMS7LZBabO9eGx6ZOEHTdi7ouDh66Y8fzdiz1AvVi1qSbUT9shMoo69j8v6UlbRy QtQGVWF18SzvCxSWBeGi+RDtHsVRS5tEF4l2TXy3Mg9e7rz2VAlEWjw6+5XkvPYbcwMlFdhvF t876YDEdd06lERoKLcgV2RO/lO2QYEgoETlTY9+umFx5Q5gGDCUbTBtJjchxTaBjz2hA2S5I4 +PvRWAWjC27c9FHwy7szux+FKYgSz1HvrNirphs9Upsvs3WqLrdMXYzOCt686+Sl5eAioy1ZF gjxqiknnAIXNZgJPj9HMQVQDdEAbrenFXitmnPC8EwJN12pUD4SHVPDwy/DWC1z7w4LUNvstP aqfi4tTjB13jm56fKB9aVjxP8WC7TEgdMPYCKtS5EMUb/M8b0Y34Jx0ITBh6LOovQIo6LDK6t iMyCxdbiYuyfTaE+aDfqIzcRirlh7yp12a6cTrWZ07F2kS6OGJpWXFUC3f2/jlcEV6l1NIu4F wpEX8oPw7JmiHL7hn29dusFkYdxv/cc6yx+J3HI/7PKkthoe+xU/vBWqg5IsXsTqx4qPDIlIC KbVpMcNgySas0edekFNkApahyk8aWXhZ/hUWsAfxJmlMtz3RCQpdU Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jun 30, 2021 at 9:55 AM Peter Zijlstra wrote: > > On Tue, Jun 29, 2021 at 09:36:23AM +0200, Arnd Bergmann wrote: > > For the specific case of cmpxchg64(), I do think it would make sense to either > > have a Kconfig symbol that controls the few users, or to provide a spinlock > > based fallback for those that don't have a native implementation. > > My preference goes to a Kconfig based solution; I so detest spinlock > based atomics. I dream of the day we can kill the lot of 'em > (sparc32-smp, parisc-smp are always the ones that come to mind). Fair enough. > This is doubly true for the xchg/cmpxchg/cmpxchg64 family of functions > that are supposed to work together with READ_ONCE/WRITE_ONCE but don't > (when 'emulated', we'd need WRITE_ONCE to also be spinlock based in > that case). Ah, I had not realized that this specifically was the problem, besides the spinlock method also being awfully slow. That means the two are already broken beyond repair, but presumably we no longer care because there are approximately zero remaining users, right? > That is, at least for atomic64_*() the whole API is self contained so we > can (and do) frob atomic64_set() to behave sanely vs atomic64_cmpxchg(). I suppose it isn't possible to completely replace cmpxchg64() and xchg64() with their atomic64() counterparts? I see there are only a handful of users, but presumably those are the ones that are not easily changed to atomic64_t. Arnd