Re: [PATCH] locking: Generic ticket lock

From: Peter Zijlstra <peterz@infradead.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: "Will Deacon" <will@kernel.org>,
	"Boqun Feng" <boqun.feng@gmail.com>,
	"Ingo Molnar" <mingo@kernel.org>,
	"Waiman Long" <longman@redhat.com>,
	linux-arch <linux-arch@vger.kernel.org>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"Guo Ren" <guoren@kernel.org>,
	"Palmer Dabbelt" <palmerdabbelt@google.com>,
	"Anup Patel" <anup@brainfault.org>,
	linux-riscv <linux-riscv@lists.infradead.org>,
	"Christoph Müllner" <christophm30@gmail.com>,
	"Stafford Horne" <shorne@gmail.com>
Subject: Re: [PATCH] locking: Generic ticket lock
Date: Thu, 21 Oct 2021 18:28:22 +0200	[thread overview]
Message-ID: <YXGVJinHk3cOVyOw@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <CAK8P3a14NUvo40GFY5DfQcF28OO22=BiHJO1TzBTEMK0RAwtHg@mail.gmail.com>

On Thu, Oct 21, 2021 at 05:31:51PM +0200, Arnd Bergmann wrote:
> On Thu, Oct 21, 2021 at 5:14 PM Peter Zijlstra <peterz@infradead.org> wrote:
> > On Thu, Oct 21, 2021 at 03:49:51PM +0200, Arnd Bergmann wrote:
> > I think for a load-store arch this thing should generate pretty close to
> > optimal code. x86 can do ticket_unlock() slightly better using a single
> > INCW (or ADDW 1) on the owner subword, where this implementation will to
> > separate load-add-store instructions.
> >
> > If that is actually measurable is something else entirely.
> 
> Ok, so I guess such an architecture could take the generic implementation
> and override just arch_spin_unlock() or just arch_spin_lock(), if that
> makes a difference for them.

Also, Pre EV5 Dec Alpha might have issues since it can only do 32bit
wide accesses, and it would need an ll/sc to unlock.

But yes, if/when needed we could allow overrides.

> Should we perhaps turn your modified openrisc asm/spinlock.h
> and asm/spin_lock_types.h the fallback in asm-generic, and
> remove the ones for the architectures that have no overrides
> at all?

Possibly, yes.

> > If your SMP arch is halfway sane (no fwd progress issues etc..) then
> > ticket should behave well and avoid the starvation/variablilty of TaS
> > lock.
> 
> Ok, and I guess we still need to keep the parisc and sparc32 versions
> anyway.

Yes, both those only have an xchg() (like) instruction and can
realistically only implement TaS locks and have to build everything else
on top of that... if only we could get rid of all that :-)

> > The big exception there is virtualized architectures, ticket is
> > absolutely horrendous for 'guests' (any fair lock is for that matter).
> 
> This might be useful information to put into the header, at least
> I had no idea about this distinction.

Yes indeed, I'd not thought of it until you asked.

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv