[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5fe76531782f4a8492b341d5f381147b@AcuMS.aculab.com>
Date: Fri, 20 Nov 2020 13:11:12 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Waiman Long' <longman@...hat.com>,
Davidlohr Bueso <dave@...olabs.net>
CC: Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...hat.com>, Will Deacon <will@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Phil Auld <pauld@...hat.com>
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.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists