Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp313774pxf; Wed, 24 Mar 2021 05:56:36 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy3N6T/kl8EtDEFXGj852SFGRUYBaMhMQWtjZjWD4+WlsQrBdYqRK7IK/opazhFmycqLadO X-Received: by 2002:a05:6402:34c4:: with SMTP id w4mr3391292edc.367.1616590596569; Wed, 24 Mar 2021 05:56:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1616590596; cv=none; d=google.com; s=arc-20160816; b=ygpZTbb0XC1+/b4FuEfOLzHk0vxFnNjRLAg1olT6BIAsFiV8KylHaBbacYNpfQSATu O8OztYm/RSEr9V6sYftexGY8GkwurzlQREbWQA3FrAGj0knwLujt6PDinXgr4eHJCAkq vwvT83uBVeWuoC/RodtkD0bpLzZkyvycPhxORFhNxsKjYQ151GXLFg/1V1Lq4uRpDqfd wRLQ73huMN2zZrzxkyAZV/FRmHtmnnKUdE/MDr8Oolj2JorB55jSwaZGG2RINSV7b9E+ aulgGrzg9VOXjiJY5O4bXnA8KF/751TOzCcCc4m8kqvsJaqiEwI5PUGVMcYSQssqWopU 9fSg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=0x8/eOR8jBnzEM8stTetLIzcLMcnZLJokgA4zekf+j0=; b=e/LEOslFn/wPFpKYWxe5cTfxAQk5QyELd+NlFcafYmeNEoNPoYnhU9EVrpWTM/8tah seKW5EFXZPSx97mIYvPPR9xJTRBTvo4sqcwtBm3XZkYwXzO0dvylrkph6ffw31zkt6kf 10wTABLXyQ/m1Ru6QN0B16UxN8bI/eV4V4f1pb3/Cd9JdYXbzo1czf27zCH9R50byq48 FxROPtsU1xpAjy+RySAr7g6JR1xFhdt0BSdg3t4cGvzBwA4eD35qAd5zgwldb/yu6rg3 xHDOPDqMiHGakON8m+t97WDX2HYnPlHtRbxkgIsR+ozuq7wOGMfCNJGrKvjqQzdWZFfR zkdA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@brainfault-org.20150623.gappssmtp.com header.s=20150623 header.b=IUsdx7gT; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id u24si1559886edy.585.2021.03.24.05.56.13; Wed, 24 Mar 2021 05:56:36 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@brainfault-org.20150623.gappssmtp.com header.s=20150623 header.b=IUsdx7gT; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234459AbhCXMyU (ORCPT + 99 others); Wed, 24 Mar 2021 08:54:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57362 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233228AbhCXMyF (ORCPT ); Wed, 24 Mar 2021 08:54:05 -0400 Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8131CC061763 for ; Wed, 24 Mar 2021 05:54:04 -0700 (PDT) Received: by mail-lf1-x135.google.com with SMTP id n138so31780479lfa.3 for ; Wed, 24 Mar 2021 05:54:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brainfault-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0x8/eOR8jBnzEM8stTetLIzcLMcnZLJokgA4zekf+j0=; b=IUsdx7gTHzToc2R8nVOw084aJxUAVpPQdGLRVFk3aSkpDZRQUSJ7a/f9KkLbM81RWy ceXojVRk5jfbOgZI4gNUC5KLnSkNaKvNLPG9EsNqDPkvoSkgbIyfJnCjCaciZyj0b7C8 DHGsVCyQPXK+pMNgaJy2znETUe1ALYjz1yzJ+WCyiWjjqCx9tteYZREiYyBVMnLM7wP6 HfAJrFlJe2QBlLD9FT+d5es32brgS9c5cY8ZUkfU6St8WIfre30ui1IRi0K1RYdxHBGC xl99QutYbN0T7beWSQ+/NZCv+1oLh9FOfwsokyVxcNNr7p6t54wtrrSB16IRoc8etrbi Ibew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0x8/eOR8jBnzEM8stTetLIzcLMcnZLJokgA4zekf+j0=; b=gSSam/LsufQHdvWm5Jv9WFV0MEYuXMb3MdGoxhwHCZu6Y0kzyWO11KIpXgrqZfFeLG rq+NqKmx/VEOgxqPqeSSk/pLa9eLG9b0kUsCoi6cgcib2eX2yt7mW0fuMV+kX1c/AHlQ UsuvA/zBIqr4VmujICMz3fd8cxRZy3V/lRVp98dE4OrEXlXLpxy2rbk19gCL7QrGQUbg DOecYgS3NFhpJH99Ywo4ylBp9u3LOhDs4M09nz47Ou0cjxuyNjfLnZNL1zkc6GMMMtk4 0yD9GDq24qBgzOkBaJf7noLTxwr7wURSBM7apj1DWp0O/40EjI6S4dMRzd5f5+89Vsk0 tpfA== X-Gm-Message-State: AOAM531iyLGe0F3nAmpRrU8ec95rxLYzuHyM0UCFj4pgdHhsLnkHljKE OIfVs+mw5cZV1tf+AKlb0l42sNPiqq0EWoVx9qHfnw== X-Received: by 2002:ac2:50d0:: with SMTP id h16mr1917793lfm.369.1616590443029; Wed, 24 Mar 2021 05:54:03 -0700 (PDT) MIME-Version: 1.0 References: <1616580892-80815-1-git-send-email-guoren@kernel.org> In-Reply-To: From: Anup Patel Date: Wed, 24 Mar 2021 18:23:51 +0530 Message-ID: Subject: Re: [PATCH] riscv: locks: introduce ticket-based spinlock implementation To: Peter Zijlstra Cc: Guo Ren , linux-riscv , "linux-kernel@vger.kernel.org List" , Guo Ren , Catalin Marinas , Will Deacon , Palmer Dabbelt , Arnd Bergmann Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 24, 2021 at 6:08 PM Peter Zijlstra wrote: > > On Wed, Mar 24, 2021 at 05:58:58PM +0530, Anup Patel wrote: > > On Wed, Mar 24, 2021 at 3:45 PM wrote: > > > > > > From: Guo Ren > > > > > > This patch introduces a ticket lock implementation for riscv, along the > > > same lines as the implementation for arch/arm & arch/csky. > > > > > > Signed-off-by: Guo Ren > > > Cc: Catalin Marinas > > > Cc: Will Deacon > > > Cc: Peter Zijlstra > > > Cc: Palmer Dabbelt > > > Cc: Anup Patel > > > Cc: Arnd Bergmann > > > --- > > > arch/riscv/Kconfig | 1 + > > > arch/riscv/include/asm/Kbuild | 1 + > > > arch/riscv/include/asm/spinlock.h | 158 ++++++++++++-------------------- > > > arch/riscv/include/asm/spinlock_types.h | 19 ++-- > > > > NACK from myside. > > > > Linux ARM64 has moved away from ticket spinlock to qspinlock. > > > > We should directly go for qspinlock. > > I think it is a sensible intermediate step, even if you want to go > qspinlock. Ticket locks are more or less trivial and get you fairness > and all that goodness without the mind bending complexity of qspinlock. > > Once you have the ticket lock implementation solid (and qrwlock) and > everything, *then* start to carefully look at qspinlock. I do understand qspinlock are relatively complex but the best thing about qspinlock is it tries to ensure each CPU spins on it's own location. Instead of adding ticket spinlock now and later replacing it with qspinlock, it is better to straight away explore qspinlock hence my NACK. > > Now, arguably arm64 did the heavy lifting of making qspinlock good on > weak architectures, but if you want to do it right, you still have to > analyze the whole thing for your own architecture. Most of the RISC-V implementations are weak memory ordering so it makes more sense to explore qspinlock first. Regards, Anup