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  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:   Fri, 20 Nov 2020 13:11:12 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Waiman Long' <>,
        Davidlohr Bueso <>
CC:     Peter Zijlstra <>,
        Ingo Molnar <>, Will Deacon <>,
        "" <>,
        Phil Auld <>
Subject: RE: [RFC PATCH 5/5] locking/rwsem: Remove reader optimistic spinning

From: Waiman Long
> Sent: 19 November 2020 18:40
> My own testing also show not too much performance difference when
> removing reader spinning except in the lightly loaded cases.

I'm confused.

I got massive performance improvements from changing a driver
we have to use mutex instead of the old semaphores (the driver
was written a long time ago).

While these weren't 'rw' the same issue will apply.

The problem was that the semaphore/mutex was typically only held over
a few instructions (eg to add an item to a list).
But with semaphore if you got contention the process always slept.
OTOH mutex spin 'for a while' before sleeping so the code rarely slept.

So I really expect that readers need to spin (for a while) if
a rwsem (etc) is locked for writing.

Clearly you really need a CBU (Crystal Ball Unit) to work out
whether to spin or not.


Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

Powered by blists - more mailing lists