From: Junichi Nomura <j-nomura@ce.jp.nec.com>
To: "Merla, ShivaKrishna" <ShivaKrishna.Merla@netapp.com>
Cc: "axboe@kernel.dk" <axboe@kernel.dk>,
device-mapper development <dm-devel@redhat.com>,
"jmoyer@redhat.com" <jmoyer@redhat.com>,
Mike Snitzer <snitzer@redhat.com>
Subject: Re: [PATCH 6/8] dm: don't start current request if it would've merged with the previous
Date: Tue, 10 Mar 2015 05:43:38 +0000 [thread overview]
Message-ID: <54FE848A.5040909@ce.jp.nec.com> (raw)
In-Reply-To: <fb15918600c64151ab7ce1f60942fee0@hioexcmbx01-prd.hq.netapp.com>
On 03/10/15 10:59, Merla, ShivaKrishna wrote:
>>> 03/09/2015 11:07:54 AM
>>> Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz
>> await r_await w_await svctm %util
>>> sdak 0.00 0.00 0.00 21737.00 0.00 101064.00 9.30 11.93 0.55
>> 0.00 0.55 0.04 93.00
>>> sdu 0.00 0.00 0.00 21759.00 0.00 101728.00 9.35 11.55 0.53
>> 0.00 0.53 0.04 93.60
>>> sdm 0.00 0.00 0.00 21669.00 0.00 101168.00 9.34 11.76 0.54
>> 0.00 0.54 0.04 94.00
>>> sdac 0.00 0.00 0.00 21812.00 0.00 101540.00 9.31 11.74 0.54
>> 0.00 0.54 0.04 92.50
>>> dm-6 0.00 14266.00 0.00 86980.00 0.00 405496.00 9.32 48.44
>> 0.56 0.00 0.56 0.01 98.70
>>>
>>> With tunable delay of 20us here are the results.
>>>
>>> 03/09/2015 11:08:43 AM
>>> Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz
>> await r_await w_await svctm %util
>>> sdak 0.00 0.00 0.00 11740.00 0.00 135344.00 23.06 4.42 0.38
>> 0.00 0.38 0.05 62.60
>>> sdu 0.00 0.00 0.00 11781.00 0.00 140800.00 23.90 3.23 0.27
>> 0.00 0.27 0.05 62.80
>>> sdm 0.00 0.00 0.00 11770.00 0.00 137592.00 23.38 4.53 0.39
>> 0.00 0.39 0.06 65.60
>>> sdac 0.00 0.00 0.00 11664.00 0.00 137976.00 23.66 3.36 0.29
>> 0.00 0.29 0.05 60.80
>>> dm-6 0.00 88446.00 0.00 46937.00 0.00 551684.00 23.51 17.88
>> 0.38 0.00 0.38 0.02 99.30
>>
>> Oh I see. Thank you.
>> So it's not that requests weren't queued for merging but that CPUs
>> could not pile the requests fast enough...
>>
>> If possible, it would be interesting to see the results with much
>> lower device queue_depth like 4 or 2.
> I think very low queue_depths will lead multipath_busy() to return 1
> even in case of large number of paths. Hence leads to better I/O merging.
Yes. But it didn't help very much..
> queue_depth 2
>
> 03/09/2015 08:47:04 PM
> Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
> sdak 0.00 0.00 0.00 10512.00 0.00 106512.00 20.26 12.60 1.20 0.00 1.20 0.10 100.00
> sdu 0.00 0.00 0.00 10546.00 0.00 105728.00 20.05 12.92 1.23 0.00 1.23 0.09 100.00
> sdm 0.00 0.00 0.00 10518.00 0.00 106108.00 20.18 12.80 1.22 0.00 1.22 0.09 99.90
> sdac 0.00 0.00 0.00 10548.00 0.00 106100.00 20.12 13.10 1.24 0.00 1.24 0.09 100.00
> dm-6 0.00 62581.00 0.00 42122.00 0.00 424420.00 20.15 53.77 1.28 0.00 1.28 0.02 100.00
>
> queue_depth 4
>
> 03/09/2015 08:54:27 PM
> Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
> sdak 0.00 0.00 0.00 15671.00 0.00 109292.00 13.95 8.64 0.55 0.00 0.55 0.06 99.80
> sdu 0.00 0.00 0.00 15733.00 0.00 109204.00 13.88 8.34 0.53 0.00 0.53 0.06 99.40
> sdm 0.00 0.00 0.00 15779.00 0.00 106788.00 13.54 8.57 0.54 0.00 0.54 0.06 99.50
> sdac 0.00 0.00 0.00 15611.00 0.00 109568.00 14.04 8.31 0.53 0.00 0.53 0.06 98.70
> dm-6 0.00 44626.00 0.00 62795.00 0.00 434832.00 13.85 36.12 0.58 0.00 0.58 0.02 100.00
--
Jun'ichi Nomura, NEC Corporation
next prev parent reply other threads:[~2015-03-10 5:43 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-04 0:47 [PATCH 0/8] dm: optimize request-based queue processing Mike Snitzer
2015-03-04 0:47 ` [PATCH 1/8] dm: remove unnecessary wrapper around blk_lld_busy Mike Snitzer
2015-03-04 0:47 ` [PATCH 2/8] dm: remove request-based DM queue's lld_busy_fn hook Mike Snitzer
2015-03-04 0:47 ` [PATCH 3/8] dm: remove request-based logic from make_request_fn wrapper Mike Snitzer
2015-03-04 0:47 ` [PATCH 4/8] dm: only run the queue on completion if congested or no requests pending Mike Snitzer
2015-03-04 0:47 ` [PATCH 5/8] dm: don't schedule delayed run of the queue if nothing to do Mike Snitzer
2015-03-04 0:47 ` [PATCH 6/8] dm: don't start current request if it would've merged with the previous Mike Snitzer
2015-03-04 6:36 ` Hannes Reinecke
2015-03-04 17:26 ` Mike Snitzer
2015-03-09 1:04 ` Junichi Nomura
2015-03-09 3:30 ` Merla, ShivaKrishna
2015-03-09 6:09 ` Junichi Nomura
2015-03-09 16:10 ` Merla, ShivaKrishna
2015-03-10 1:05 ` Junichi Nomura
2015-03-10 1:59 ` Merla, ShivaKrishna
2015-03-10 5:43 ` Junichi Nomura [this message]
2015-03-04 0:47 ` [PATCH 7/8] dm sysfs: introduce ability to add writable attributes Mike Snitzer
2015-03-04 0:47 ` [PATCH 8/8] dm: impose configurable deadline for dm_request_fn's merge heuristic Mike Snitzer
2015-03-06 15:30 ` [PATCH 8/8 v2] " Mike Snitzer
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=54FE848A.5040909@ce.jp.nec.com \
--to=j-nomura@ce.jp.nec.com \
--cc=ShivaKrishna.Merla@netapp.com \
--cc=axboe@kernel.dk \
--cc=dm-devel@redhat.com \
--cc=jmoyer@redhat.com \
--cc=snitzer@redhat.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 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.