[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YHbpUtIWaaP1Qod1@hirez.programming.kicks-ass.net>
Date: Wed, 14 Apr 2021 15:08:34 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Guo Ren <guoren@...nel.org>
Cc: Christoph Müllner <christophm30@...il.com>,
Palmer Dabbelt <palmer@...belt.com>,
Anup Patel <anup@...infault.org>,
linux-riscv <linux-riscv@...ts.infradead.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Guo Ren <guoren@...ux.alibaba.com>,
Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will.deacon@....com>,
Arnd Bergmann <arnd@...db.de>, Jonas Bonn <jonas@...thpole.se>,
Stefan Kristiansson <stefan.kristiansson@...nalahti.fi>,
Stafford Horne <shorne@...il.com>
Subject: Re: [RFC][PATCH] locking: Generic ticket-lock
On Wed, Apr 14, 2021 at 02:55:57PM +0200, Peter Zijlstra wrote:
> On Wed, Apr 14, 2021 at 08:39:33PM +0800, Guo Ren wrote:
> > > + * It further assumes atomic_*_release() + atomic_*_acquire() is RCpc and hence
> > > + * uses atomic_fetch_add() which is SC to create an RCsc lock.
>
> This ^^^ then vvv
>
> > > +static __always_inline void ticket_lock(arch_spinlock_t *lock)
> > > +{
> > > + u32 val = atomic_fetch_add(1<<16, lock); /* SC, gives us RCsc */
> > atomic_fetch_add_acquire ?
>
> Then we must rely on the arch to implement RCsc atomics. And I for one
> can never tell wth Risc-V actually does.
Anyway, if we can mandate that atomic acquire/release is RCsc, then yes
we can do that but then we also need:
#define smp_mb__after_spinlock() smp_mb__after_atomic()
But currently atomic acquire/release is not RCsc (at the very least
Power does RCtso -- and power gets to deal with any and all pain caused
by that).
Powered by blists - more mailing lists