linux-kernel - Re: [PATCH-tip 3/3] locking/rwsem: Stop active read lock ASAP

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: <6966e39f-78cf-7968-8d4a-a0a1fbe8f676@redhat.com>
Date:   Mon, 27 Feb 2017 10:07:45 -0500
From:   Waiman Long <longman@...hat.com>
To:     Davidlohr Bueso <dave@...olabs.net>
Cc:     Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH-tip 3/3] locking/rwsem: Stop active read lock ASAP

On 02/26/2017 01:58 PM, Davidlohr Bueso wrote:
> On Wed, 22 Feb 2017, Waiman Long wrote:
>
>> On a 2-socket 36-core 72-thread x86-64 E5-2699 v3 system, a rwsem
>> microbenchmark was run with 36 locking threads (one/core) doing 100k
>> reader and writer lock/unlock operations each, the resulting locking
>> rates (avg of 3 runs) on a 4.10 kernel were 561.4 Mop/s and 588.8
>> Mop/s without and with the patch respectively. That was an increase
>> of about 5%.
>
> iirc this patch is a repost, no? If so, did you get a chance to measure
> single file access with direct io as dchinner suggested?
>
> Thanks,
> Davidlohr

Yes, this patch is a derivative of part of the rwsem reader spinning
patch set that I posted before. The major change here in this patch is
from the unconditional spitting into 2 atomic adds to a conditional
spitting depending the on OSQ state and the ability to acquire the
wait_lock immediately without waiting. This should reduce the concern
that you have with the original patch. I will run a single-file direct
I/O test as well. 

Cheers,
Longman