From: Waiman Long <waiman.long@hp.com>
To: Davidlohr Bueso <davidlohr@hp.com>
Cc: Ingo Molnar <mingo@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
linux-kernel@vger.kernel.org, linux-api@vger.kernel.org,
linux-doc@vger.kernel.org, Jason Low <jason.low2@hp.com>,
Scott J Norton <scott.norton@hp.com>
Subject: Re: [PATCH 0/7] locking/rwsem: enable reader opt-spinning & writer respin
Date: Mon, 04 Aug 2014 14:07:48 -0400 [thread overview]
Message-ID: <53DFCBF4.5010904@hp.com> (raw)
In-Reply-To: <1407126313.3216.10.camel@buesod1.americas.hpqcorp.net>
On 08/04/2014 12:25 AM, Davidlohr Bueso wrote:
> On Sun, 2014-08-03 at 22:36 -0400, Waiman Long wrote:
>> This patch set improves upon the rwsem optimistic spinning patch set
>> from Davidlohr to enable better performing rwsem and more aggressive
>> use of optimistic spinning.
>>
>> By using a microbenchmark running 1 million lock-unlock operations per
>> thread on a 4-socket 40-core Westmere-EX x86-64 test machine running
>> 3.16-rc7 based kernels, the following table shows the execution times
>> with 2/10 threads running on different CPUs on the same socket where
>> load is the number of pause instructions in the critical section:
>>
>> lock/r:w ratio # of threads Load:Execution Time (ms)
>> -------------- ------------ ------------------------
>> mutex 2 1:530.7, 5:406.0, 10:472.7
>> mutex 10 1:1848 , 5:2046 , 10:4394
>>
>> Before patch:
>> rwsem/0:1 2 1:339.4, 5:368.9, 10:394.0
>> rwsem/1:1 2 1:2915 , 5:2621 , 10:2764
>> rwsem/10:1 2 1:891.2, 5:779.2, 10:827.2
>> rwsem/0:1 10 1:5618 , 5:5722 , 10:5683
>> rwsem/1:1 10 1:14562, 5:14561, 10:14770
>> rwsem/10:1 10 1:5914 , 5:5971 , 10:5912
>>
>> After patch:
>> rwsem/0:1 2 1:161.1, 5:244.4, 10:271.4
>> rwsem/1:1 2 1:188.8, 5:212.4, 10:312.9
>> rwsem/10:1 2 1:168.8, 5:179.5, 10:209.8
>> rwsem/0:1 10 1:1306 , 5:1733 , 10:1998
>> rwsem/1:1 10 1:1512 , 5:1602 , 10:2093
>> rwsem/10:1 10 1:1267 , 5:1458 , 10:2233
>>
>> % Change:
>> rwsem/0:1 2 1:-52.5%, 5:-33.7%, 10:-31.1%
>> rwsem/1:1 2 1:-93.5%, 5:-91.9%, 10:-88.7%
>> rwsem/10:1 2 1:-81.1%, 5:-77.0%, 10:-74.6%
>> rwsem/0:1 10 1:-76.8%, 5:-69.7%, 10:-64.8%
>> rwsem/1:1 10 1:-89.6%, 5:-89.0%, 10:-85.8%
>> rwsem/10:1 10 1:-78.6%, 5:-75.6%, 10:-62.2%
> So at a very low level you see nicer results, which aren't really
> translating to much of a significant impact at a higher level (aim7).
I was using a 4-socket system for testing. I believe the performance
gain will be higher on larger machine. I will run some tests on those
larger machine as well.
>> It can be seen that there is dramatic reduction in the execution
>> times. The new rwsem is now even faster than mutex whether it is all
>> writers or a mixture of writers and readers.
>>
>> Running the AIM7 benchmarks on the same 40-core system (HT off),
>> the performance improvements on some of the workloads were as follows:
>>
>> Workload Before Patch After Patch % Change
>> -------- ------------ ----------- --------
>> custom (200-1000) 446135 477404 +7.0%
>> custom (1100-2000) 449665 484734 +7.8%
>> high_systime 152437 154217 +1.2%
>> (200-1000)
>> high_systime 269695 278942 +3.4%
>> (1100-2000)
> I worry about complicating rwsems even _more_ than they are, specially
> for such a marginal gain. You might want to try other workloads -- ie:
> postgresql (pgbench), I normally get pretty useful data when dealing
> with rwsems.
>
Thank for the info. I will try running pgbench as well.
-Longman
prev parent reply other threads:[~2014-08-04 18:07 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-04 2:36 [PATCH 0/7] locking/rwsem: enable reader opt-spinning & writer respin Waiman Long
2014-08-04 2:36 ` [PATCH 1/7] locking/rwsem: don't resched at the end of optimistic spinning Waiman Long
2014-08-04 7:55 ` Peter Zijlstra
2014-08-04 18:36 ` Waiman Long
2014-08-04 20:48 ` Peter Zijlstra
2014-08-04 21:12 ` Jason Low
2014-08-05 17:54 ` Waiman Long
2014-08-04 2:36 ` [PATCH 2/7] locking/rwsem: more aggressive use " Waiman Long
2014-08-04 4:09 ` Davidlohr Bueso
2014-08-04 4:10 ` Jason Low
2014-08-04 15:44 ` Waiman Long
2014-08-13 5:51 ` Dave Chinner
2014-08-13 16:41 ` Waiman Long
2014-08-15 3:34 ` Dave Chinner
2014-08-15 17:58 ` Waiman Long
2014-08-16 7:40 ` Mike Galbraith
2014-08-17 23:41 ` Dave Chinner
2014-08-18 22:48 ` Waiman Long
2014-08-04 2:36 ` [PATCH 3/7] locking/rwsem: check for active writer/spinner before wakeup Waiman Long
2014-08-04 21:20 ` Jason Low
2014-08-05 17:56 ` Waiman Long
2014-08-04 2:36 ` [PATCH 4/7] locking/rwsem: threshold limited spinning for active readers Waiman Long
2014-08-05 4:54 ` Davidlohr Bueso
2014-08-05 5:30 ` Davidlohr Bueso
2014-08-05 5:41 ` Davidlohr Bueso
2014-08-05 18:14 ` Waiman Long
2014-08-04 2:36 ` [PATCH 5/7] locking/rwsem: move down rwsem_down_read_failed function Waiman Long
2014-08-04 2:36 ` [PATCH 6/7] locking/rwsem: enables optimistic spinning for readers Waiman Long
2014-08-04 2:36 ` [PATCH 7/7] locking/rwsem: allow waiting writers to go back to optimistic spinning Waiman Long
2014-08-04 4:25 ` [PATCH 0/7] locking/rwsem: enable reader opt-spinning & writer respin Davidlohr Bueso
2014-08-04 18:07 ` Waiman Long [this message]
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=53DFCBF4.5010904@hp.com \
--to=waiman.long@hp.com \
--cc=davidlohr@hp.com \
--cc=jason.low2@hp.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=scott.norton@hp.com \
/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).