linux-kernel - Re: [PATCH v2] locking/rwsem: Take read lock immediate if queue empty with no writer

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <9722ffd0-9adb-9ad1-a05b-25869c0b2e60@redhat.com>
Date:   Mon, 23 Jul 2018 09:40:58 -0400
From:   Waiman Long <longman@...hat.com>
To:     Davidlohr Bueso <dave@...olabs.net>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...hat.com>,
        Will Deacon <will.deacon@....com>,
        linux-kernel@...r.kernel.org, Mark Ray <mark.ray@....com>,
        Joe Mario <jmario@...hat.com>,
        Scott Norton <scott.norton@....com>
Subject: Re: [PATCH v2] locking/rwsem: Take read lock immediate if queue empty
 with no writer

On 07/23/2018 12:04 AM, Davidlohr Bueso wrote:
> On Wed, 18 Jul 2018, Waiman Long wrote:
>
>> The key here is that we don't want other incoming readers to observe
>> that there are waiters in the wait queue and hence have to go into the
>> slowpath until the single waiter in the queue is sure that it probably
>> will need to go to sleep if there is writer.
>>
>> With a constant stream of incoming readers, a major portion of them will
>> observe the a negative count and be serialized to enter the slowpath.
>> There are certainly other readers that do not observe the negative count
>> in the in between period after one reader clear the count in the unlock
>> path and a waiter set the count to negative again. Those readers can go
>> ahead and do the read in parallel. But it is the serialized readers that
>> cause the performance loss and the observation of spinlock contention in
>> the perf output.
>
> This makes sense and seems feasible in that the optimization is done with
> the wait_lock held.
>
>>
>> It is the constant stream of incoming readers that sustain the spinlock
>> queue and the repeated clearing and negative setting of the count.
>
> This would not affect optimistic spinners that haven't yet arrived at the
> waitqueue phase because the lock is anonymously owned, so they won't spin
> in the first place, right?

The reader fastpath would have incremented the active count before
entering the slowpath. The spinning writer, seeing a non-zero active
count, will not attempt to steal the lock until the reader decrement the
count and set the waiting bias in one atomic op. Nothing will happen
before that.

-Longman