Re: [PATCH 3/5] locking/rwsem: add down_read[_killable]_nosteal()

[David Hildenbrand (Arm)]

On 11/3/26 13:24, Lorenzo Stoakes (ARM) wrote:
> On Tue, Nov 03, 2026 at 12:51:59PM +0100, Peter Zijlstra wrote:
>> On Tue, Nov 03, 2026 at 08:27:44AM +0000, Lorenzo Stoakes (ARM) wrote:
>>> Since commit 1a728dff855a ("locking/rwsem: Enable reader optimistic lock
>>> stealing") a sleeping, queued writer whose handoff timeout hasn't expired
>>> can have its lock stolen by a read lock issued before a woken queued writer
>>> was able to acquire a lock.
>>>
>>> To avoid write lock starvation, this is only permitted if no other read
>>> locks are held.
>>>
>>> However, this behaviour defeats the purpose of a reader periodically
>>> dropping the lock to allow writers in, as doing so only works if the write
>>> lock is acquired first, another read lock is held, or a queued writer's
>>> handoff timeout has expired.
>>>
>>> Provide a means of indicating this intent via down_read_nosteal() and
>>> down_read_killable_nosteal().
>>>
>>> Implement it by exposing a steal parameter to rwsem_down_read_slowpath(),
>>> update the starvation logic to modify this parameter and modify the steal
>>> branch to check it first.
>>>
>>> Also drop the duplicated RWSEM_WRITER_LOCKED check and remove the
>>> goto as the steal condition makes this redundant.
>>>
>>> Exposing this function is safe as it only makes the lock more pessimistic,
>>> so does not impact lock contention.
>>
>> Not generally a fan of this -- can't we tweak the steal thing to never
>> steal if there are pending writers?
> 
> Oh, well, I had assumed I couldn't fiddle with that behaviour across
> rwsem's in general, so if I can yeah that's preferable!
> 
> I could send that change separately then and drop it out of this series.

Just so I understand correctly, this patch here would be gone entirely?

But #4 depends on it, so now I'm confused :)

-- 
Cheers,

David