[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <68d07068-ff31-26b5-f90d-7ea8b4ee2389@redhat.com>
Date: Fri, 20 Nov 2020 12:04:24 -0500
From: Waiman Long <longman@...hat.com>
To: David Laight <David.Laight@...LAB.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
On 11/20/20 8:11 AM, David Laight wrote:
> 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.
That is the hard part. For short critical section and not many readers
around, making the readers spin will likely improve performance. On the
other hand, if the critical section is long with many readers, make
readers sleep and then wake them all up at once can have better
performance. There is no one-size-fit-all solution here.
Cheers,
Longman
Powered by blists - more mailing lists