From: Dave Chinner <david@fromorbit.com>
To: Waiman Long <longman@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
linux-kernel@vger.kernel.org, x86@kernel.org,
linux-alpha@vger.kernel.org, linux-ia64@vger.kernel.org,
linux-s390@vger.kernel.org, linux-arch@vger.kernel.org,
Davidlohr Bueso <dave@stgolabs.net>
Subject: Re: [PATCH v6 00/11] locking/rwsem: Rework rwsem-xadd & enable new rwsem features
Date: Thu, 12 Oct 2017 07:50:33 +1100 [thread overview]
Message-ID: <20171011205033.GK15067@dastard> (raw)
In-Reply-To: <1507744922-15196-1-git-send-email-longman@redhat.com>
On Wed, Oct 11, 2017 at 02:01:51PM -0400, Waiman Long wrote:
> In term of rwsem performance, a rwsem microbenchmark and fio randrw
> test with a xfs filesystem on a ramdisk were used to verify the
> performance changes due to these patches. Both tests were run on a
> 2-socket, 40-core Gold 6148 system. The rwsem microbenchmark (1:1
> reader/writer ratio) has short critical section while the fio randrw
> test has long critical section (4k read/write).
>
> The following table shows the performance of the rwsem microbenchmark
> and fio radrw test with different number of patches applied on 4.14
> based kernels:
>
> # of Patches Locking Rate FIO Bandwidth FIO Bandwidth
> Applied 40 threads 32 threads 16 threads
> ------------ ------------ ------------- -------------
> 0 38.7 kop/s 706 MB/s 704 MB/s
> 7 38.6 kop/s 668 MB/s 663 MB/s
> 8 38.9 kop/s 704 MB/s 701 MB/s
> 9 39.1 kop/s 702 MB/s 707 MB/s
> 11 3218.0 kop/s 2594 MB/s 2614 MB/s
>
> So this patchset improves mixed read/write rwsem microbench by 83X
> and randrw fio bandwidth by about 3.7X.
Overall improvement in bandwidth is not necessarily a good thing -
this could simply demonstrate total write bandwidth starvation and
so it's only reporting read bandwith. It's much more important to
look at the change in read bandwidth vs write bandwidth in the fio
test. i.e. exactly how did the IO balance change as a result of
changing the locking bias?
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
WARNING: multiple messages have this Message-ID (diff)
From: Dave Chinner <david@fromorbit.com>
To: Waiman Long <longman@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
linux-kernel@vger.kernel.org, x86@kernel.org,
linux-alpha@vger.kernel.org, linux-ia64@vger.kernel.org,
linux-s390@vger.kernel.org, linux-arch@vger.kernel.org,
Davidlohr Bueso <dave@stgolabs.net>
Subject: Re: [PATCH v6 00/11] locking/rwsem: Rework rwsem-xadd & enable new rwsem features
Date: Wed, 11 Oct 2017 20:50:33 +0000 [thread overview]
Message-ID: <20171011205033.GK15067@dastard> (raw)
In-Reply-To: <1507744922-15196-1-git-send-email-longman@redhat.com>
On Wed, Oct 11, 2017 at 02:01:51PM -0400, Waiman Long wrote:
> In term of rwsem performance, a rwsem microbenchmark and fio randrw
> test with a xfs filesystem on a ramdisk were used to verify the
> performance changes due to these patches. Both tests were run on a
> 2-socket, 40-core Gold 6148 system. The rwsem microbenchmark (1:1
> reader/writer ratio) has short critical section while the fio randrw
> test has long critical section (4k read/write).
>
> The following table shows the performance of the rwsem microbenchmark
> and fio radrw test with different number of patches applied on 4.14
> based kernels:
>
> # of Patches Locking Rate FIO Bandwidth FIO Bandwidth
> Applied 40 threads 32 threads 16 threads
> ------------ ------------ ------------- -------------
> 0 38.7 kop/s 706 MB/s 704 MB/s
> 7 38.6 kop/s 668 MB/s 663 MB/s
> 8 38.9 kop/s 704 MB/s 701 MB/s
> 9 39.1 kop/s 702 MB/s 707 MB/s
> 11 3218.0 kop/s 2594 MB/s 2614 MB/s
>
> So this patchset improves mixed read/write rwsem microbench by 83X
> and randrw fio bandwidth by about 3.7X.
Overall improvement in bandwidth is not necessarily a good thing -
this could simply demonstrate total write bandwidth starvation and
so it's only reporting read bandwith. It's much more important to
look at the change in read bandwidth vs write bandwidth in the fio
test. i.e. exactly how did the IO balance change as a result of
changing the locking bias?
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2017-10-11 20:50 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-11 18:01 [PATCH v6 00/11] locking/rwsem: Rework rwsem-xadd & enable new rwsem features Waiman Long
2017-10-11 18:01 ` Waiman Long
2017-10-11 18:01 ` [PATCH v6 01/11] locking/rwsem: relocate rwsem_down_read_failed() Waiman Long
2017-10-11 18:01 ` Waiman Long
2017-10-11 18:01 ` [PATCH v6 02/11] locking/rwsem: Implement a new locking scheme Waiman Long
2017-10-11 18:01 ` Waiman Long
2017-10-11 18:40 ` Peter Zijlstra
2017-10-11 18:40 ` Peter Zijlstra
2017-10-11 18:58 ` Waiman Long
2017-10-11 18:58 ` Waiman Long
2017-10-11 19:05 ` Waiman Long
2017-10-11 19:05 ` Waiman Long
2017-10-11 19:36 ` Peter Zijlstra
2017-10-11 19:36 ` Peter Zijlstra
2017-10-11 18:01 ` [PATCH v6 03/11] locking/rwsem: Move owner setting code from rwsem.c to rwsem-xadd.h Waiman Long
2017-10-11 18:01 ` Waiman Long
2017-10-11 18:01 ` [PATCH v6 04/11] locking/rwsem: Remove kernel/locking/rwsem.h Waiman Long
2017-10-11 18:01 ` Waiman Long
2017-10-11 18:01 ` [PATCH v6 05/11] locking/rwsem: Move rwsem internal function declarations to rwsem-xadd.h Waiman Long
2017-10-11 18:01 ` Waiman Long
2017-10-11 18:01 ` [PATCH v6 06/11] locking/rwsem: Remove arch specific rwsem files Waiman Long
2017-10-11 18:01 ` Waiman Long
2017-10-11 18:01 ` [PATCH v6 07/11] locking/rwsem: Implement lock handoff to prevent lock starvation Waiman Long
2017-10-11 18:01 ` Waiman Long
2017-10-11 18:01 ` [PATCH v6 08/11] locking/rwsem: Enable readers spinning on writer Waiman Long
2017-10-11 18:01 ` Waiman Long
2017-10-11 18:02 ` [PATCH v6 09/11] locking/rwsem: Enable time-based reader lock stealing Waiman Long
2017-10-11 18:02 ` Waiman Long
2017-10-11 18:02 ` [PATCH v6 10/11] locking/rwsem: Make rwsem_spin_on_owner() return a tri-state value Waiman Long
2017-10-11 18:02 ` Waiman Long
2017-10-11 18:02 ` [PATCH v6 11/11] locking/rwsem: Enable count-based spinning on reader Waiman Long
2017-10-11 18:02 ` Waiman Long
2017-10-11 18:48 ` [PATCH v6 00/11] locking/rwsem: Rework rwsem-xadd & enable new rwsem features Peter Zijlstra
2017-10-11 18:48 ` Peter Zijlstra
2017-10-11 18:50 ` Waiman Long
2017-10-11 18:50 ` Waiman Long
2017-10-11 20:45 ` Dave Chinner
2017-10-11 20:45 ` Dave Chinner
2017-10-11 20:50 ` Dave Chinner [this message]
2017-10-11 20:50 ` Dave Chinner
2017-10-11 20:57 ` Waiman Long
2017-10-11 20:57 ` Waiman Long
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=20171011205033.GK15067@dastard \
--to=david@fromorbit.com \
--cc=dave@stgolabs.net \
--cc=linux-alpha@vger.kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=longman@redhat.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=x86@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.