Messages in this thread | | | Date | Tue, 11 May 2021 09:46:05 +0200 | From | Peter Zijlstra <> | Subject | Re: [PATCH 02/17] locking: Add split_lock |
| |
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.
| |