Re: [PATCH v2 1/2] Revert "locking/rwsem: Remove reader optimistic spinning"

[Waiman Long <longman@redhat.com>]

On 9/6/23 07:27, Bongkyu Kim wrote:
> On Mon, Sep 04, 2023 at 03:56:56PM -0400, Waiman Long wrote:
>> On 9/4/23 11:10, Peter Zijlstra wrote:
>>> On Fri, Sep 01, 2023 at 10:07:03AM +0900, Bongkyu Kim wrote:
>>>> This reverts commit 617f3ef95177840c77f59c2aec1029d27d5547d6.
>>>>
>>>> In mobile environment, reader optimistic spinning is still useful
>>>> because there're not many readers. In my test result at android device,
>>>> it improves application startup time about 3.8%
>>>> App startup time is most important factor for android user expriences.
>>>> So, re-enable reader optimistic spinning by this commit. And,
>>>> the later patch will make it optional feature by cmdline.
>>> I'm not seeing any mention on how this interacts with all the rwsem work
>>> that has been done since that commit, like the handoff rework.
>>>
>>> Why is a straight revert a sane thing at this point?
>> I also agree that a revert is not the best way to reintroduce the feature.
>> It should document the reason why reader optimistic spinning is not the
>> default as discussed in commit 617f3ef9517 ("locking/rwsem: Remove reader
>> optimistic spinning") and under what condition should reader optimistic
>> spinning can be turned back on.
>>
>> Besides, I now think we may not really need 2 separate nonspinnable bits. We
>> can go with one that is set by writer timing out when spinning on reader.
>>
>> Cheers,
>> Longman
> Should I modify like the below?
> - Title to "locking/rwsem: Reintroduce reader optimistic spinning"
> - Add more document like Longman's comment
> - Reconsidering about 2 separate nonspinnable bits to one

Besides the above, Peter also ask to verify that it won't affect handoff 
handling which requires that an unlocker see the lock will be free and 
wake up the head of the wait queue. Given the fact that the simple 
heuristic of skipping optimistic spinning if the lock is reader owned is 
kept, that shouldn't be a problem, but you still need to document that.

Cheers,
Longman