Re: [PATCH v2 01/20] locking/rt: Use raw_spin_lock_irqsave() in __rwbase_read_unlock()

[David Woodhouse]

On Fri, 2026-05-29 at 22:38 +0200, Peter Zijlstra wrote:
> On Fri, May 29, 2026 at 10:13:35PM +0200, Peter Zijlstra wrote:
> 
> > It is somewhat possible to do an RT aware read-write spinlock thing, but
> > it is definitely non-trivial and this would be the only user.
> 
> Furthermore, it is fundamentally one of the worst possible lock types.
> 
> It really isn't something you *want* to have -- arguably even for !RT.
> 
> They scale like ass; per them being a spinlock type, the critical
> sections must be short, but this means there is nothing to amortize the
> cost of bouncing the shared lock around -- which is the 'saving' grace
> of the rwsem.
> 
> For short sections the cost of the shared access will dominate. I'm sure
> Paul has a bunch of graphs to illustrate this point :-)

Most of these are per-vCPU anyway. I think the only one that isn't is
the Xen shared_info page, and we *could* have a GPC for that per vCPU
if we really wanted. 

In *theory* we could be delivering hardware interrupts as event
channels from multiple physical CPUs simultaneously. But that's
probably fairly rare, at least for them all to be coming to the same
vCPU.

So in the general case, they don't bounce around much unless someone
else takes a write lock to invalidate them.

I suspect we could tolerate them being a raw_spin_lock on RT and only a
rwlock on non-RT, if there's no appetite for raw_rwlock?

Attachment: smime.p7s
Description: S/MIME cryptographic signature