From: Waiman Long <longman@redhat.com>
To: Davidlohr Bueso <dave@stgolabs.net>
Cc: Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>, Will Deacon <will@kernel.org>,
linux-kernel@vger.kernel.org, Phil Auld <pauld@redhat.com>
Subject: Re: [RFC PATCH 5/5] locking/rwsem: Remove reader optimistic spinning
Date: Thu, 19 Nov 2020 13:40:05 -0500 [thread overview]
Message-ID: <ee34bc01-9fef-23ff-ada1-1ec2d39533c9@redhat.com> (raw)
In-Reply-To: <20201118053556.3fmmtat7upv6dtvd@linux-p48b.lan>
On 11/18/20 12:35 AM, Davidlohr Bueso wrote:
> On Tue, 17 Nov 2020, Waiman Long wrote:
>
>> The column "CS Load" represents the number of pause instructions issued
>> in the locking critical section. A CS load of 1 is extremely short and
>> is not likey in real situations. A load of 20 (moderate) and 100 (long)
>> are more realistic.
>>
>> It can be seen that the previous patches in this series have reduced
>> performance in general except in highly contended cases with moderate
>> or long critical sections that performance improves a bit. This change
>> is mostly caused by the "Prevent potential lock starvation" patch that
>> reduce reader optimistic spinning and hence reduce reader fragmentation.
>>
>> The patch that further limit reader optimistic spinning doesn't seem to
>> have too much impact on overall performance as shown in the benchmark
>> data.
>>
>> The patch that disables reader optimistic spinning shows reduced
>> performance at lightly loaded cases, but comparable or slightly better
>> performance on with heavier contention.
>
> I'm not overly worried about the lightly loaded cases here as the users
> (mostly thinking mmap_sem) most likely won't care for real workloads,
> not, ie: will-it-scale type things.
I am not that worry about the lightly loaded cases either. I just state
the fact that some workloads may see a slightly reduced performance
because of that.
>
> So at SUSE we also ran into this very same problem with reader optimistic
> spinning and considering the fragmentation went with disabling it, much
> like this patch - but without the reader optimistic lock stealing bits
> you have. So far nothing has really shown to fall out in our performance
> automation. And per your data a single reader spinner does not seem to be
> worth the added complexity of keeping reader spinning vs ripping it out.
My own testing also show not too much performance difference when
removing reader spinning except in the lightly loaded cases.
Cheers,
Longman
next prev parent reply other threads:[~2020-11-19 18:40 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-18 3:04 [PATCH 0/5] locking/rwsem: Rework reader optimistic spinning Waiman Long
2020-11-18 3:04 ` [PATCH 1/5] locking/rwsem: Pass the current atomic count to rwsem_down_read_slowpath() Waiman Long
2020-11-18 3:04 ` [PATCH 2/5] locking/rwsem: Prevent potential lock starvation Waiman Long
2020-11-20 14:44 ` Peter Zijlstra
2020-11-20 17:27 ` Waiman Long
2020-11-18 3:04 ` [PATCH 3/5] locking/rwsem: Enable reader optimistic lock stealing Waiman Long
2020-11-20 14:36 ` Peter Zijlstra
2020-11-20 17:26 ` Waiman Long
2020-12-08 3:53 ` Davidlohr Bueso
2020-11-18 3:04 ` [PATCH 4/5] locking/rwsem: Wake up all waiting readers if RWSEM_WAKE_READ_OWNED Waiman Long
2020-11-18 4:53 ` Davidlohr Bueso
2020-11-19 18:37 ` Waiman Long
2020-11-18 3:04 ` [RFC PATCH 5/5] locking/rwsem: Remove reader optimistic spinning Waiman Long
2020-11-18 5:35 ` Davidlohr Bueso
2020-11-19 18:40 ` Waiman Long [this message]
2020-11-20 13:11 ` David Laight
2020-11-20 17:04 ` Waiman Long
2020-11-20 17:37 ` David Laight
2020-11-20 21:38 ` Davidlohr Bueso
2020-11-21 11:50 ` David Laight
2020-11-20 14:44 ` Peter Zijlstra
2020-11-20 22:39 ` Waiman Long
2020-11-20 14:42 ` Peter Zijlstra
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ee34bc01-9fef-23ff-ada1-1ec2d39533c9@redhat.com \
--to=longman@redhat.com \
--cc=dave@stgolabs.net \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=pauld@redhat.com \
--cc=peterz@infradead.org \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).