[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YGG6Ms5Rl0AOJL2i@hirez.programming.kicks-ass.net>
Date: Mon, 29 Mar 2021 13:29:54 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Arnd Bergmann <arnd@...db.de>
Cc: Guo Ren <guoren@...nel.org>,
linux-riscv <linux-riscv@...ts.infradead.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-csky@...r.kernel.org,
linux-arch <linux-arch@...r.kernel.org>,
Guo Ren <guoren@...ux.alibaba.com>,
Will Deacon <will@...nel.org>, Ingo Molnar <mingo@...hat.com>,
Waiman Long <longman@...hat.com>,
Anup Patel <anup@...infault.org>,
Sebastian Andrzej Siewior <sebastian@...akpoint.cc>
Subject: Re: [PATCH v4 3/4] locking/qspinlock: Add
ARCH_USE_QUEUED_SPINLOCKS_XCHG32
On Mon, Mar 29, 2021 at 01:16:53PM +0200, Peter Zijlstra wrote:
> Anyway, an additional 'funny' is that I suspect you cannot prove fwd
> progress of the entire primitive with any of this on. But who cares
> about details anyway.. :/
What's the architectural guarantee on LL/SC progress for RISC-V ? And
what if you double loop it like cmpxchg() ?
Powered by blists - more mailing lists