From: Bart Van Assche <Bart.VanAssche@wdc.com>
To: "ming.lei@redhat.com" <ming.lei@redhat.com>
Cc: "linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
"hch@infradead.org" <hch@infradead.org>,
"tom.leiming@gmail.com" <tom.leiming@gmail.com>,
"sagi@grimberg.me" <sagi@grimberg.me>,
"snitzer@redhat.com" <snitzer@redhat.com>,
"martin.petersen@oracle.com" <martin.petersen@oracle.com>,
"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
"axboe@fb.com" <axboe@fb.com>,
"linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>,
"jejb@linux.vnet.ibm.com" <jejb@linux.vnet.ibm.com>,
"loberman@redhat.com" <loberman@redhat.com>,
"dm-devel@redhat.com" <dm-devel@redhat.com>
Subject: Re: [PATCH 1/5] block: don't call blk_mq_delay_run_hw_queue() in case of BLK_STS_RESOURCE
Date: Tue, 19 Sep 2017 23:25:47 +0000 [thread overview]
Message-ID: <1505863546.2671.55.camel@wdc.com> (raw)
In-Reply-To: <20170919224410.GA21829@ming.t460p>
On Wed, 2017-09-20 at 06:44 +0800, Ming Lei wrote:
> For this issue, it isn't same between SCSI and dm-rq.
>
> We don't need to run queue in .end_io of dm, and the theory is
> simple, otherwise it isn't performance issue, and should be I/O hang.
>
> 1) every dm-rq's request is 1:1 mapped to SCSI's request
>
> 2) if there is any mapped SCSI request not finished, either
> in-flight or in requeue list or whatever, there will be one
> corresponding dm-rq's request in-flight
>
> 3) once the mapped SCSI request is completed, dm-rq's completion
> path will be triggered and dm-rq's queue will be rerun because of
> SCHED_RESTART in dm-rq
>
> So the hw queue of dm-rq has been run in dm-rq's completion path
> already, right? Why do we need to do it again in the hot path?
The measurement data in the description of patch 5/5 shows a significant
performance regression for an important workload, namely random I/O.
Additionally, the performance improvement for sequential I/O was achieved
for an unrealistically low queue depth. Sorry but given these measurement
results I don't see why I should spend more time on this patch series.
Bart.
WARNING: multiple messages have this Message-ID (diff)
From: Bart Van Assche <Bart.VanAssche@wdc.com>
To: "ming.lei@redhat.com" <ming.lei@redhat.com>
Cc: "linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
"hch@infradead.org" <hch@infradead.org>,
"tom.leiming@gmail.com" <tom.leiming@gmail.com>,
"sagi@grimberg.me" <sagi@grimberg.me>,
"snitzer@redhat.com" <snitzer@redhat.com>,
"martin.petersen@oracle.com" <martin.petersen@oracle.com>,
"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
"axboe@fb.com" <axboe@fb.com>,
"linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>,
"jejb@linux.vnet.ibm.com" <jejb@linux.vnet.ibm.com>,
"loberman@redhat.com" <loberman@redhat.com>,
"dm-devel@redhat.com" <dm-devel@redhat.com>
Subject: Re: [PATCH 1/5] block: don't call blk_mq_delay_run_hw_queue() in case of BLK_STS_RESOURCE
Date: Tue, 19 Sep 2017 23:25:47 +0000 [thread overview]
Message-ID: <1505863546.2671.55.camel@wdc.com> (raw)
In-Reply-To: <20170919224410.GA21829@ming.t460p>
T24gV2VkLCAyMDE3LTA5LTIwIGF0IDA2OjQ0ICswODAwLCBNaW5nIExlaSB3cm90ZToNCj4gRm9y
IHRoaXMgaXNzdWUsIGl0IGlzbid0IHNhbWUgYmV0d2VlbiBTQ1NJIGFuZCBkbS1ycS4NCj4gDQo+
IFdlIGRvbid0IG5lZWQgdG8gcnVuIHF1ZXVlIGluIC5lbmRfaW8gb2YgZG0sIGFuZCB0aGUgdGhl
b3J5IGlzDQo+IHNpbXBsZSwgb3RoZXJ3aXNlIGl0IGlzbid0IHBlcmZvcm1hbmNlIGlzc3VlLCBh
bmQgc2hvdWxkIGJlIEkvTyBoYW5nLg0KPiANCj4gMSkgZXZlcnkgZG0tcnEncyByZXF1ZXN0IGlz
IDE6MSBtYXBwZWQgdG8gU0NTSSdzIHJlcXVlc3QNCj4gDQo+IDIpIGlmIHRoZXJlIGlzIGFueSBt
YXBwZWQgU0NTSSByZXF1ZXN0IG5vdCBmaW5pc2hlZCwgZWl0aGVyDQo+IGluLWZsaWdodCBvciBp
biByZXF1ZXVlIGxpc3Qgb3Igd2hhdGV2ZXIsIHRoZXJlIHdpbGwgYmUgb25lDQo+IGNvcnJlc3Bv
bmRpbmcgZG0tcnEncyByZXF1ZXN0IGluLWZsaWdodA0KPiANCj4gMykgb25jZSB0aGUgbWFwcGVk
IFNDU0kgcmVxdWVzdCBpcyBjb21wbGV0ZWQsIGRtLXJxJ3MgY29tcGxldGlvbg0KPiBwYXRoIHdp
bGwgYmUgdHJpZ2dlcmVkIGFuZCBkbS1ycSdzIHF1ZXVlIHdpbGwgYmUgcmVydW4gYmVjYXVzZSBv
Zg0KPiBTQ0hFRF9SRVNUQVJUIGluIGRtLXJxDQo+IA0KPiBTbyB0aGUgaHcgcXVldWUgb2YgZG0t
cnEgaGFzIGJlZW4gcnVuIGluIGRtLXJxJ3MgY29tcGxldGlvbiBwYXRoDQo+IGFscmVhZHksIHJp
Z2h0PyBXaHkgZG8gd2UgbmVlZCB0byBkbyBpdCBhZ2FpbiBpbiB0aGUgaG90IHBhdGg/DQoNClRo
ZSBtZWFzdXJlbWVudCBkYXRhIGluIHRoZSBkZXNjcmlwdGlvbiBvZiBwYXRjaCA1LzUgc2hvd3Mg
YSBzaWduaWZpY2FudA0KcGVyZm9ybWFuY2UgcmVncmVzc2lvbiBmb3IgYW4gaW1wb3J0YW50IHdv
cmtsb2FkLCBuYW1lbHkgcmFuZG9tIEkvTy4NCkFkZGl0aW9uYWxseSwgdGhlIHBlcmZvcm1hbmNl
IGltcHJvdmVtZW50IGZvciBzZXF1ZW50aWFsIEkvTyB3YXMgYWNoaWV2ZWQNCmZvciBhbiB1bnJl
YWxpc3RpY2FsbHkgbG93IHF1ZXVlIGRlcHRoLiBTb3JyeSBidXQgZ2l2ZW4gdGhlc2UgbWVhc3Vy
ZW1lbnQNCnJlc3VsdHMgSSBkb24ndCBzZWUgd2h5IEkgc2hvdWxkIHNwZW5kIG1vcmUgdGltZSBv
biB0aGlzIHBhdGNoIHNlcmllcy4NCg0KQmFydC4=
WARNING: multiple messages have this Message-ID (diff)
From: Bart.VanAssche@wdc.com (Bart Van Assche)
Subject: [PATCH 1/5] block: don't call blk_mq_delay_run_hw_queue() in case of BLK_STS_RESOURCE
Date: Tue, 19 Sep 2017 23:25:47 +0000 [thread overview]
Message-ID: <1505863546.2671.55.camel@wdc.com> (raw)
In-Reply-To: <20170919224410.GA21829@ming.t460p>
On Wed, 2017-09-20@06:44 +0800, Ming Lei wrote:
> For this issue, it isn't same between SCSI and dm-rq.
>
> We don't need to run queue in .end_io of dm, and the theory is
> simple, otherwise it isn't performance issue, and should be I/O hang.
>
> 1) every dm-rq's request is 1:1 mapped to SCSI's request
>
> 2) if there is any mapped SCSI request not finished, either
> in-flight or in requeue list or whatever, there will be one
> corresponding dm-rq's request in-flight
>
> 3) once the mapped SCSI request is completed, dm-rq's completion
> path will be triggered and dm-rq's queue will be rerun because of
> SCHED_RESTART in dm-rq
>
> So the hw queue of dm-rq has been run in dm-rq's completion path
> already, right? Why do we need to do it again in the hot path?
The measurement data in the description of patch 5/5 shows a significant
performance regression for an important workload, namely random I/O.
Additionally, the performance improvement for sequential I/O was achieved
for an unrealistically low queue depth. Sorry but given these measurement
results I don't see why I should spend more time on this patch series.
Bart.
next prev parent reply other threads:[~2017-09-19 23:25 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-15 16:44 [PATCH 0/5] dm-mpath: improve I/O schedule Ming Lei
2017-09-15 16:44 ` Ming Lei
2017-09-15 16:44 ` [PATCH 1/5] block: don't call blk_mq_delay_run_hw_queue() in case of BLK_STS_RESOURCE Ming Lei
2017-09-15 16:44 ` Ming Lei
2017-09-15 17:57 ` Bart Van Assche
2017-09-15 17:57 ` Bart Van Assche
2017-09-15 17:57 ` Bart Van Assche
2017-09-17 12:40 ` Ming Lei
2017-09-17 12:40 ` Ming Lei
2017-09-18 15:18 ` Bart Van Assche
2017-09-18 15:18 ` Bart Van Assche
2017-09-18 15:18 ` Bart Van Assche
2017-09-19 5:43 ` Ming Lei
2017-09-19 5:43 ` Ming Lei
2017-09-19 15:36 ` Bart Van Assche
2017-09-19 15:36 ` Bart Van Assche
2017-09-19 15:36 ` Bart Van Assche
2017-09-19 15:56 ` Mike Snitzer
2017-09-19 15:56 ` Mike Snitzer
2017-09-19 16:04 ` Ming Lei
2017-09-19 16:04 ` Ming Lei
2017-09-19 16:49 ` Bart Van Assche
2017-09-19 16:49 ` Bart Van Assche
2017-09-19 16:49 ` Bart Van Assche
2017-09-19 16:55 ` Ming Lei
2017-09-19 16:55 ` Ming Lei
2017-09-19 18:42 ` Bart Van Assche
2017-09-19 18:42 ` Bart Van Assche
2017-09-19 18:42 ` Bart Van Assche
2017-09-19 22:44 ` Ming Lei
2017-09-19 22:44 ` Ming Lei
2017-09-19 23:25 ` Bart Van Assche [this message]
2017-09-19 23:25 ` Bart Van Assche
2017-09-19 23:25 ` Bart Van Assche
2017-09-19 23:50 ` Mike Snitzer
2017-09-19 23:50 ` Mike Snitzer
2017-09-20 1:13 ` Ming Lei
2017-09-20 1:13 ` Ming Lei
2017-09-20 1:19 ` Ming Lei
2017-09-20 1:19 ` Ming Lei
2017-09-19 15:48 ` Mike Snitzer
2017-09-19 15:48 ` Mike Snitzer
2017-09-19 15:52 ` Bart Van Assche
2017-09-19 15:52 ` Bart Van Assche
2017-09-19 15:52 ` Bart Van Assche
2017-09-19 16:03 ` Mike Snitzer
2017-09-19 16:03 ` Mike Snitzer
2017-09-19 16:07 ` Ming Lei
2017-09-19 16:07 ` Ming Lei
2017-09-15 16:44 ` [PATCH 2/5] dm-mpath: return DM_MAPIO_REQUEUE in case of rq allocation failure Ming Lei
2017-09-15 17:29 ` Bart Van Assche
2017-09-15 17:29 ` Bart Van Assche
2017-09-15 20:06 ` Mike Snitzer
2017-09-15 20:48 ` Bart Van Assche
2017-09-15 20:48 ` Bart Van Assche
2017-09-17 13:23 ` Ming Lei
2017-09-19 14:41 ` Mike Snitzer
2017-09-19 15:56 ` Ming Lei
2017-09-17 12:51 ` Ming Lei
2017-09-15 16:44 ` [PATCH 3/5] dm-mpath: remove annoying message of 'blk_get_request() returned -11' Ming Lei
2017-09-15 16:44 ` [PATCH 4/5] block: export blk_update_nr_requests Ming Lei
2017-09-15 16:44 ` [PATCH 5/5] dm-mpath: improve I/O schedule Ming Lei
2017-09-15 20:10 ` Mike Snitzer
2017-09-15 20:56 ` Bart Van Assche
2017-09-15 20:56 ` Bart Van Assche
2017-09-15 21:06 ` Bart Van Assche
2017-09-15 21:06 ` Bart Van Assche
2017-09-15 21:42 ` Bart Van Assche
2017-09-15 21:42 ` Bart Van Assche
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=1505863546.2671.55.camel@wdc.com \
--to=bart.vanassche@wdc.com \
--cc=axboe@fb.com \
--cc=dm-devel@redhat.com \
--cc=hch@infradead.org \
--cc=jejb@linux.vnet.ibm.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=linux-scsi@vger.kernel.org \
--cc=loberman@redhat.com \
--cc=martin.petersen@oracle.com \
--cc=ming.lei@redhat.com \
--cc=sagi@grimberg.me \
--cc=snitzer@redhat.com \
--cc=tom.leiming@gmail.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.