Received: by 2002:a05:6a10:6d10:0:0:0:0 with SMTP id gq16csp981705pxb; Fri, 15 Apr 2022 17:19:58 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyuDO2GCyGHmHkgO/rzEFCoBP2Ri6+VFaZR7X6gcjsllNO+CC7zFYBSTqSjD9y6Zc4lJWjM X-Received: by 2002:a05:6a00:10cc:b0:505:ada6:e03e with SMTP id d12-20020a056a0010cc00b00505ada6e03emr1327232pfu.45.1650068398450; Fri, 15 Apr 2022 17:19:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1650068398; cv=none; d=google.com; s=arc-20160816; b=PYKXBFUi06ndT/r2WmYbxL99hqHkP7CdbkYIk8X/8O+It9SZq7k6r/vCkVjzJxF5gb JZaBsh9/2JgPgTQ9IJXwBemFsmtwWDaGU/SfdyOi6yLj/fjPk2V3WVOB88xmebvYoZaw sKo0oY23y140W3vBQvK2JXG+dqhzfT74Mnu4S6gwGizPqGrjvk97kcfz/DyfkPUWKMgT Mg7AN2Bu79Bmki1TIBYv13+ETjLK16orTSxvLT6bdTh6cvcD2jh4mWh1lAMVk316Eov5 UWRdbtcBNzNhTBb9q4k59ergb1aclubRK7l6pLQ7n9JF8KyrJT++M/r36DicXGiEESP4 MbcA== 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 :message-id:to:from:cc:in-reply-to:subject:date:dkim-signature; bh=ItPn/AcYuP2hdhsdSFglkfktyf1iLOm6R95lIRQYTZY=; b=VQXmP2SMtZh6WHwXgGZES3bOw7y6OleICiyrUefLGLHndPwzlHghZDCh1WMNqU0Fky RzDbr3ACEdIDnyh6tCyf3J+Y6bPsHuKQ+/Iva228yX/YohXyI8xym3Vo4iRUfM7+q0lX r/8CSTxJoQ3ERJnGhhj5YzALAZMtIXiSF2pyLIO8IBY4I5/p9DE9sgB1hkgtskJNE8B5 zl8rrH1AJCd+qWm3/5jz4pmDfTZOfkuDuojO6b7K8YG2c309IJ/Mjt65uPqtRftsPXH3 D73dqGxTc6f7iqeUxkRWgv8Mpmfyr7fTGEhkJHZPtAYX0P4JP+eXXio1EBH+fXUlQ12s RnEw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@rivosinc-com.20210112.gappssmtp.com header.s=20210112 header.b=JS96M1iH; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id r17-20020a170902be1100b00153bc4c0a7fsi2356042pls.593.2022.04.15.17.19.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 Apr 2022 17:19:58 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@rivosinc-com.20210112.gappssmtp.com header.s=20210112 header.b=JS96M1iH; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 16BE6CA6CF; Fri, 15 Apr 2022 17:19:08 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345443AbiDOQs6 (ORCPT + 99 others); Fri, 15 Apr 2022 12:48:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55082 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236184AbiDOQs5 (ORCPT ); Fri, 15 Apr 2022 12:48:57 -0400 Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C6284396A8 for ; Fri, 15 Apr 2022 09:46:27 -0700 (PDT) Received: by mail-pl1-x629.google.com with SMTP id n18so7521915plg.5 for ; Fri, 15 Apr 2022 09:46:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20210112.gappssmtp.com; s=20210112; h=date:subject:in-reply-to:cc:from:to:message-id:mime-version :content-transfer-encoding; bh=ItPn/AcYuP2hdhsdSFglkfktyf1iLOm6R95lIRQYTZY=; b=JS96M1iHtXQEhUuFoqlaiZ2VRIlhckrTO6Ij+BqZyqgaE8i/vjuqr3iwPAM31Qe1pU nVGCc2V86N2/l3lhhwmPjSe+1NSVhGrWzLgz01qOgzQpML3gf0R2zensKqD9EirmUpcE keaKxzUHNn1xgI6Ls/PKoYT1oVMsK2wrQheR4OS/uc8dFCOVM6IsONgT2L0PgunTiA35 5DalFyKEsd6ZwfsEeVL0Cycuepa9OKvPgJQPsWST2LX9Dr2+MNc4Hb4I83m7qtMnvHiK Ypti60XVTPZP+yryoYLh3SP85K+fLvWwD5h709bL4SEOMSDO1MXhHVCnYGWETmkkQaqc eRRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:subject:in-reply-to:cc:from:to:message-id :mime-version:content-transfer-encoding; bh=ItPn/AcYuP2hdhsdSFglkfktyf1iLOm6R95lIRQYTZY=; b=fRaU4FujzysbmDlDKVGqtWwQe7FA7BLSYDD+HygyWTnTUTqwKIkgpCYuIn5YZBst+f I/kkfgO/TqjyvaFxyW9w6W55gyqdnjylJBG/Hg9UTa5IU6yOCW3b8afXfWSBaFMzSjV5 5MiRGUDD0oHdQIx6DJ26+1t6RxnMB8COJ2S7ddjUyr5zQU9A5VY6z2tVOXW6j4ydddFw 0jf6SxTHKfLEdOzzi6XPYoi4hSZ/F9DcTd3w3E9J82mheOIbQ4ue5NUNxu55u1Q/GF4S R3ewrZvYwV9dzHLYcaOq/QMG0ZQSEYzMZF6NHk6D+dEoAxsNoH6d7ixdEeL6TxhyX9tZ r1MA== X-Gm-Message-State: AOAM532ia+hZhyhT78Ok7lLxjErMaJN/F5FHpdUN35tREanK67VvWYJA iUAGxLqBQYrgEf/VTFaThYeb4w== X-Received: by 2002:a17:90b:3882:b0:1cd:41c1:712a with SMTP id mu2-20020a17090b388200b001cd41c1712amr5110813pjb.72.1650041187144; Fri, 15 Apr 2022 09:46:27 -0700 (PDT) Received: from localhost ([12.3.194.138]) by smtp.gmail.com with ESMTPSA id d16-20020a056a00245000b004f7728a4346sm3584771pfj.79.2022.04.15.09.46.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 Apr 2022 09:46:26 -0700 (PDT) Date: Fri, 15 Apr 2022 09:46:26 -0700 (PDT) X-Google-Original-Date: Fri, 15 Apr 2022 09:46:08 PDT (-0700) Subject: Re: [PATCH v3 1/7] asm-generic: ticket-lock: New generic ticket-based spinlock In-Reply-To: <1e26726b-721e-7197-8834-8aff2b4c4bc3@redhat.com> CC: Arnd Bergmann , heiko@sntech.de, guoren@kernel.org, shorne@gmail.com, peterz@infradead.org, mingo@redhat.com, Will Deacon , boqun.feng@gmail.com, jonas@southpole.se, stefan.kristiansson@saunalahti.fi, Paul Walmsley , aou@eecs.berkeley.edu, macro@orcam.me.uk, Greg KH , sudipm.mukherjee@gmail.com, wangkefeng.wang@huawei.com, jszhang@kernel.org, linux-csky@vger.kernel.org, linux-kernel@vger.kernel.org, openrisc@lists.librecores.org, linux-riscv@lists.infradead.org, linux-arch@vger.kernel.org From: Palmer Dabbelt To: longman@redhat.com Message-ID: Mime-Version: 1.0 (MHng) Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RDNS_NONE, SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no 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: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 14 Apr 2022 18:27:12 PDT (-0700), longman@redhat.com wrote: > On 4/14/22 18:02, Palmer Dabbelt wrote: >> From: Peter Zijlstra >> >> This is a simple, fair spinlock. Specifically it doesn't have all the >> subtle memory model dependencies that qspinlock has, which makes it more >> suitable for simple systems as it is more likely to be correct. It is >> implemented entirely in terms of standard atomics and thus works fine >> without any arch-specific code. >> >> This replaces the existing asm-generic/spinlock.h, which just errored >> out on SMP systems. >> >> Signed-off-by: Peter Zijlstra (Intel) >> Signed-off-by: Palmer Dabbelt >> --- >> include/asm-generic/spinlock.h | 85 +++++++++++++++++++++++++--- >> include/asm-generic/spinlock_types.h | 17 ++++++ >> 2 files changed, 94 insertions(+), 8 deletions(-) >> create mode 100644 include/asm-generic/spinlock_types.h >> >> diff --git a/include/asm-generic/spinlock.h b/include/asm-generic/spinlock.h >> index adaf6acab172..ca829fcb9672 100644 >> --- a/include/asm-generic/spinlock.h >> +++ b/include/asm-generic/spinlock.h >> @@ -1,12 +1,81 @@ >> /* SPDX-License-Identifier: GPL-2.0 */ >> -#ifndef __ASM_GENERIC_SPINLOCK_H >> -#define __ASM_GENERIC_SPINLOCK_H >> + >> /* >> - * You need to implement asm/spinlock.h for SMP support. The generic >> - * version does not handle SMP. >> + * 'Generic' ticket-lock implementation. >> + * >> + * It relies on atomic_fetch_add() having well defined forward progress >> + * guarantees under contention. If your architecture cannot provide this, stick >> + * to a test-and-set lock. >> + * >> + * It also relies on atomic_fetch_add() being safe vs smp_store_release() on a >> + * sub-word of the value. This is generally true for anything LL/SC although >> + * you'd be hard pressed to find anything useful in architecture specifications >> + * about this. If your architecture cannot do this you might be better off with >> + * a test-and-set. >> + * >> + * It further assumes atomic_*_release() + atomic_*_acquire() is RCpc and hence >> + * uses atomic_fetch_add() which is SC to create an RCsc lock. >> + * >> + * The implementation uses smp_cond_load_acquire() to spin, so if the >> + * architecture has WFE like instructions to sleep instead of poll for word >> + * modifications be sure to implement that (see ARM64 for example). >> + * >> */ >> -#ifdef CONFIG_SMP >> -#error need an architecture specific asm/spinlock.h >> -#endif >> >> -#endif /* __ASM_GENERIC_SPINLOCK_H */ >> +#ifndef __ASM_GENERIC_TICKET_LOCK_H >> +#define __ASM_GENERIC_TICKET_LOCK_H > It is not conventional to use a macro name that is different from the > header file name. Sorry, that was just a mistake: I renamed the header, but forgot to rename the guard. I'll likely send a v4 due to Boqun's questions, I'll fix this as well. >> + >> +#include >> +#include >> + >> +static __always_inline void arch_spin_lock(arch_spinlock_t *lock) >> +{ >> + u32 val = atomic_fetch_add(1<<16, lock); /* SC, gives us RCsc */ >> + u16 ticket = val >> 16; >> + >> + if (ticket == (u16)val) >> + return; >> + >> + atomic_cond_read_acquire(lock, ticket == (u16)VAL); >> +} >> + >> +static __always_inline bool arch_spin_trylock(arch_spinlock_t *lock) >> +{ >> + u32 old = atomic_read(lock); >> + >> + if ((old >> 16) != (old & 0xffff)) >> + return false; >> + >> + return atomic_try_cmpxchg(lock, &old, old + (1<<16)); /* SC, for RCsc */ >> +} >> + >> +static __always_inline void arch_spin_unlock(arch_spinlock_t *lock) >> +{ >> + u16 *ptr = (u16 *)lock + IS_ENABLED(CONFIG_CPU_BIG_ENDIAN); >> + u32 val = atomic_read(lock); >> + >> + smp_store_release(ptr, (u16)val + 1); >> +} >> + >> +static __always_inline int arch_spin_is_locked(arch_spinlock_t *lock) >> +{ >> + u32 val = atomic_read(lock); >> + >> + return ((val >> 16) != (val & 0xffff)); >> +} >> + >> +static __always_inline int arch_spin_is_contended(arch_spinlock_t *lock) >> +{ >> + u32 val = atomic_read(lock); >> + >> + return (s16)((val >> 16) - (val & 0xffff)) > 1; >> +} >> + >> +static __always_inline int arch_spin_value_unlocked(arch_spinlock_t lock) >> +{ >> + return !arch_spin_is_locked(&lock); >> +} >> + >> +#include >> + >> +#endif /* __ASM_GENERIC_TICKET_LOCK_H */ >> diff --git a/include/asm-generic/spinlock_types.h b/include/asm-generic/spinlock_types.h >> new file mode 100644 >> index 000000000000..e56ddb84d030 >> --- /dev/null >> +++ b/include/asm-generic/spinlock_types.h >> @@ -0,0 +1,17 @@ >> +/* SPDX-License-Identifier: GPL-2.0 */ >> + >> +#ifndef __ASM_GENERIC_TICKET_LOCK_TYPES_H >> +#define __ASM_GENERIC_TICKET_LOCK_TYPES_H >> + >> +#include >> +typedef atomic_t arch_spinlock_t; >> + >> +/* >> + * qrwlock_types depends on arch_spinlock_t, so we must typedef that before the >> + * include. >> + */ >> +#include > > I believe that if you guard the include line by > > #ifdef CONFIG_QUEUED_RWLOCK > #include > #endif > > You may not need to do the hack in patch 5. Yes, and we actually had it that way the first time around (specifically the ARCH_USES_QUEUED_RWLOCKS, but IIUC that's the same here). The goal was to avoid adding the ifdef to the asm-generic code and instead keep the oddness in arch/riscv, it's only there for that one commit (and just so we can split out the spinlock conversion from the rwlock conversion, in case there's a bug and these need to be bisected later). I'd also considered renaming qrwlock* to rwlock*, which would avoid the ifdef and make it a touch easier to override the rwlock implementation, but that didn't seem useful enough to warrant the diff. These all seem a bit more coupled than I expected them to be (both {spin,qrw}lock{,_types}.h and the bits in linux/), I looked into cleaning that up a bit but it seemed like too much for just the one patch set. > You can also directly use the line without > importing it to include/asm. Yes, along with qrwlock.h (which has some unnecessary #include shims in a handful of arch dirs). That's going to make the patch set bigger, I'll include it in the v4. Thanks!