[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20201118030429.23017-1-longman@redhat.com>
Date: Tue, 17 Nov 2020 22:04:24 -0500
From: Waiman Long <longman@...hat.com>
To: Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...hat.com>, Will Deacon <will@...nel.org>
Cc: linux-kernel@...r.kernel.org, Davidlohr Bueso <dave@...olabs.net>,
Phil Auld <pauld@...hat.com>, Waiman Long <longman@...hat.com>
Subject: [PATCH 0/5] locking/rwsem: Rework reader optimistic spinning
A recent report of SAP certification failure caused by increased system
time due to rwsem reader optimistic spinning led me to reexamine the
code to see the pro and cons of doing it. This led me to discover a
potential lock starvation scenario as explained in patch 2. That patch
does reduce reader spinning to avoid this potential problem. Patches
3 and 4 are further optimizations of the current code.
Then there is the issue of reader fragmentation that can potentially
reduce performance in some heavy contention cases. Two different approaches
are attempted:
1) further reduce reader optimistic spinning
2) disable reader spinning
See the performance shown in patch 5.
This patch series adopts the second approach by dropping reader spinning
for now. We can discuss if this is the right move or we should try the
alternative or just don't do anything further.
Waiman Long (5):
locking/rwsem: Pass the current atomic count to
rwsem_down_read_slowpath()
locking/rwsem: Prevent potential lock starvation
locking/rwsem: Enable reader optimistic lock stealing
locking/rwsem: Wake up all waiting readers if RWSEM_WAKE_READ_OWNED
locking/rwsem: Remove reader optimistic spinning
kernel/locking/lock_events_list.h | 6 +-
kernel/locking/rwsem.c | 277 ++++++++----------------------
2 files changed, 73 insertions(+), 210 deletions(-)
--
2.18.1
Powered by blists - more mailing lists