[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK8P3a2+=9jjyqN5dMOb4+bYJy=q5G3CxFaCW+=4xryz-S=zYA@mail.gmail.com>
Date: Thu, 21 Oct 2021 15:49:51 +0200
From: Arnd Bergmann <arnd@...db.de>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Will Deacon <will@...nel.org>, Boqun Feng <boqun.feng@...il.com>,
Ingo Molnar <mingo@...nel.org>,
Waiman Long <longman@...hat.com>,
Arnd Bergmann <arnd@...db.de>,
linux-arch <linux-arch@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Guo Ren <guoren@...nel.org>,
Palmer Dabbelt <palmerdabbelt@...gle.com>,
Anup Patel <anup@...infault.org>,
linux-riscv <linux-riscv@...ts.infradead.org>,
Christoph Müllner <christophm30@...il.com>,
Stafford Horne <shorne@...il.com>
Subject: Re: [PATCH] locking: Generic ticket lock
On Thu, Oct 21, 2021 at 3:05 PM Peter Zijlstra <peterz@...radead.org> wrote:
>
> Therefore provide ticket locks, which depend on a single atomic
> operation (fetch_add) while still providing fairness.
Nice!
Aside from the qspinlock vs ticket-lock question, can you describe the
tradeoffs between this generic ticket lock and a custom implementation
in architecture code? Should we convert most architectures over
to the generic code in the long run, or is there something they
can usually do better with an inline asm based ticket lock or
a trivial test-and-set?
> Signed-off-by: Peter Zijlstra (Intel) <peterz@...radead.org>
> ---
> include/asm-generic/qspinlock.h | 30 +++++++++
> include/asm-generic/ticket_lock_types.h | 11 +++
> include/asm-generic/ticket_lock.h | 97 ++++++++++++++++++++++++++++++++
> 3 files changed, 138 insertions(+)
If anyone wants to use this for their architecture, feel free to add
Acked-by: Arnd Bergmann <arnd@...db.de>
to merge it through the respective architecture git tree. If there is more
than one architecture that wants it right now, I could also take them
all through
the asm-generic tree.
Arnd
Powered by blists - more mailing lists