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] [thread-next>] [day] [month] [year] [list]

Date:   Sun, 22 Jul 2018 21:04:23 -0700
From:   Davidlohr Bueso <dave@...olabs.net>
To:     Waiman Long <longman@...hat.com>
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 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?

Thanks,
Davidlohr