Re: [PATCH 02/17] locking: Add split_lock

[Peter Zijlstra <peterz@infradead.org>]

On Mon, Apr 12, 2021 at 03:45:25PM +0100, Matthew Wilcox wrote:
> On Mon, Apr 12, 2021 at 04:29:28PM +0200, Thomas Gleixner wrote:
> > is to have a place to stick the lockdep map into. So it's not a lock
> > construct as the name suggests, it's just auxiliary data when lockdep is
> > enabled.
> 
> That's the implementation _today_, but conceptually, it's a single lock.
> I was thinking that for non-RT, we could put a qspinlock in there for a
> thread to spin on if the bit is contended.  It'd need a bit of ingenuity
> to make sure that a thread unlocking a bitlock made sure that a thread
> spinning on the qspinlock saw the wakeup, but it should be doable.

queued_write_lock_slowpath() does more or less exactly what you
describe.

I just worry about loss of concurrency if we were to do that. Where
currently we could be spinning on 5 different hash buckets and make
individual progress, doing what you propose would limit that.

Imagine having one bit-spinlock taken and another cpu contending, it
would go into the queue. Then do the same with another bit-spinlock,
with another two CPUs, the second again goes into that same queue.

So now we have 2 CPUs owning a bit-spinlock, and 2 CPUs stuck in the
queue. Suppose the second bit-spinlock is released, this would make the
queue-tail elegible to aquire, but it's stuck behind the queue-head
which is still waiting for its bit-spinlock. So it'll stay queued and we
loose concurrency.

Anyway, I think all this is worthwhile just to get bit-spinlock lockdep
coverage. And it's not like we can't change any of this when/if we get a
better idea or something.