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=-12.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=unavailable 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 2B874C63798 for ; Wed, 25 Nov 2020 14:31:52 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id BC70F206D9 for ; Wed, 25 Nov 2020 14:31:50 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="MioyNkE3" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729477AbgKYObf (ORCPT ); Wed, 25 Nov 2020 09:31:35 -0500 Received: from mail.kernel.org ([198.145.29.99]:40510 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729344AbgKYObf (ORCPT ); Wed, 25 Nov 2020 09:31:35 -0500 Received: from willie-the-truck (236.31.169.217.in-addr.arpa [217.169.31.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 20CE8206F9; Wed, 25 Nov 2020 14:31:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1606314694; bh=wKP1QfRaO0pncarWwIy2eBfABvq24Ar8n3NiWBXx3OU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=MioyNkE3mbyp3ub95NlYgl3ZcvcJcJyYbY2ao46SMGhg61vQsfvJFKVqQF4hU8uSV G95Y/uxJXhZEOxB9C4rqXTJWjrsZKhSKOLgdCF09sfzMd02EcsUndBN7qbCLoTH4b1 OL/HEyB5iCiB2DJUH7PLKA3peeYaa4Gm0QOnHNdA= Date: Wed, 25 Nov 2020 14:31:28 +0000 From: Will Deacon To: Peter Zijlstra Cc: Arnd Bergmann , Guo Ren , Arnd Bergmann , Palmer Dabbelt , Paul Walmsley , Anup Patel , linux-riscv , "linux-kernel@vger.kernel.org" , linux-csky@vger.kernel.org, Guo Ren , Michael Clark Subject: Re: [PATCH 2/5] riscv: Add QUEUED_SPINLOCKS & QUEUED_RWLOCKS supported Message-ID: <20201125143128.GC16159@willie-the-truck> References: <1606225437-22948-1-git-send-email-guoren@kernel.org> <1606225437-22948-2-git-send-email-guoren@kernel.org> <20201124143931.GI2414@hirez.programming.kicks-ass.net> <20201125141645.GB2414@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201125141645.GB2414@hirez.programming.kicks-ass.net> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-csky@vger.kernel.org On Wed, Nov 25, 2020 at 03:16:45PM +0100, Peter Zijlstra wrote: > @@ -207,6 +187,32 @@ static __always_inline void clear_pending_set_locked(struct qspinlock *lock) > atomic_add(-_Q_PENDING_VAL + _Q_LOCKED_VAL, &lock->val); > } > > +#endif /* _Q_PENDING_BITS == 8 */ > + > +#if _Q_PENDING_BITS == 8 && ARCH_HAS_XCHG16 > + > +/* > + * xchg_tail - Put in the new queue tail code word & retrieve previous one > + * @lock : Pointer to queued spinlock structure > + * @tail : The new queue tail code word > + * Return: The previous queue tail code word > + * > + * xchg(lock, tail), which heads an address dependency > + * > + * p,*,* -> n,*,* ; prev = xchg(lock, node) > + */ > +static __always_inline u32 xchg_tail(struct qspinlock *lock, u32 tail) > +{ > + /* > + * We can use relaxed semantics since the caller ensures that the > + * MCS node is properly initialized before updating the tail. > + */ > + return (u32)xchg_relaxed(&lock->tail, > + tail >> _Q_TAIL_OFFSET) << _Q_TAIL_OFFSET; > +} > + > +#else /* !(_Q_PENDING_BITS == 8 && ARCH_HAS_XCHG16) */ Why can't architectures just implement this with a 32-bit xchg instruction if they don't have one that operates on 16 bits? Sure, they'll store more data, but it's atomic so you shouldn't be able to tell... (ignoring parisc crazy). Also, I'm surprised qspinlock benefits riscv. On arm64, there's nothing in it over tickets for <= 16 CPUs. Will