diff for duplicates of <1505863546.2671.55.camel@wdc.com> diff --git a/a/1.txt b/N1/1.txt index d052aa1..7484cad 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,26 +1,21 @@ -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. +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= diff --git a/a/content_digest b/N1/content_digest index 82b925b..6fb08ab 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -27,31 +27,26 @@ " dm-devel@redhat.com <dm-devel@redhat.com>\0" "\00:1\0" "b\0" - "On Wed, 2017-09-20 at 06:44 +0800, Ming Lei wrote:\n" - "> For this issue, it isn't same between SCSI and dm-rq.\n" - "> \n" - "> We don't need to run queue in .end_io of dm, and the theory is\n" - "> simple, otherwise it isn't performance issue, and should be I/O hang.\n" - "> \n" - "> 1) every dm-rq's request is 1:1 mapped to SCSI's request\n" - "> \n" - "> 2) if there is any mapped SCSI request not finished, either\n" - "> in-flight or in requeue list or whatever, there will be one\n" - "> corresponding dm-rq's request in-flight\n" - "> \n" - "> 3) once the mapped SCSI request is completed, dm-rq's completion\n" - "> path will be triggered and dm-rq's queue will be rerun because of\n" - "> SCHED_RESTART in dm-rq\n" - "> \n" - "> So the hw queue of dm-rq has been run in dm-rq's completion path\n" - "> already, right? Why do we need to do it again in the hot path?\n" - "\n" - "The measurement data in the description of patch 5/5 shows a significant\n" - "performance regression for an important workload, namely random I/O.\n" - "Additionally, the performance improvement for sequential I/O was achieved\n" - "for an unrealistically low queue depth. Sorry but given these measurement\n" - "results I don't see why I should spend more time on this patch series.\n" - "\n" - Bart. + "T24gV2VkLCAyMDE3LTA5LTIwIGF0IDA2OjQ0ICswODAwLCBNaW5nIExlaSB3cm90ZToNCj4gRm9y\n" + "IHRoaXMgaXNzdWUsIGl0IGlzbid0IHNhbWUgYmV0d2VlbiBTQ1NJIGFuZCBkbS1ycS4NCj4gDQo+\n" + "IFdlIGRvbid0IG5lZWQgdG8gcnVuIHF1ZXVlIGluIC5lbmRfaW8gb2YgZG0sIGFuZCB0aGUgdGhl\n" + "b3J5IGlzDQo+IHNpbXBsZSwgb3RoZXJ3aXNlIGl0IGlzbid0IHBlcmZvcm1hbmNlIGlzc3VlLCBh\n" + "bmQgc2hvdWxkIGJlIEkvTyBoYW5nLg0KPiANCj4gMSkgZXZlcnkgZG0tcnEncyByZXF1ZXN0IGlz\n" + "IDE6MSBtYXBwZWQgdG8gU0NTSSdzIHJlcXVlc3QNCj4gDQo+IDIpIGlmIHRoZXJlIGlzIGFueSBt\n" + "YXBwZWQgU0NTSSByZXF1ZXN0IG5vdCBmaW5pc2hlZCwgZWl0aGVyDQo+IGluLWZsaWdodCBvciBp\n" + "biByZXF1ZXVlIGxpc3Qgb3Igd2hhdGV2ZXIsIHRoZXJlIHdpbGwgYmUgb25lDQo+IGNvcnJlc3Bv\n" + "bmRpbmcgZG0tcnEncyByZXF1ZXN0IGluLWZsaWdodA0KPiANCj4gMykgb25jZSB0aGUgbWFwcGVk\n" + "IFNDU0kgcmVxdWVzdCBpcyBjb21wbGV0ZWQsIGRtLXJxJ3MgY29tcGxldGlvbg0KPiBwYXRoIHdp\n" + "bGwgYmUgdHJpZ2dlcmVkIGFuZCBkbS1ycSdzIHF1ZXVlIHdpbGwgYmUgcmVydW4gYmVjYXVzZSBv\n" + "Zg0KPiBTQ0hFRF9SRVNUQVJUIGluIGRtLXJxDQo+IA0KPiBTbyB0aGUgaHcgcXVldWUgb2YgZG0t\n" + "cnEgaGFzIGJlZW4gcnVuIGluIGRtLXJxJ3MgY29tcGxldGlvbiBwYXRoDQo+IGFscmVhZHksIHJp\n" + "Z2h0PyBXaHkgZG8gd2UgbmVlZCB0byBkbyBpdCBhZ2FpbiBpbiB0aGUgaG90IHBhdGg/DQoNClRo\n" + "ZSBtZWFzdXJlbWVudCBkYXRhIGluIHRoZSBkZXNjcmlwdGlvbiBvZiBwYXRjaCA1LzUgc2hvd3Mg\n" + "YSBzaWduaWZpY2FudA0KcGVyZm9ybWFuY2UgcmVncmVzc2lvbiBmb3IgYW4gaW1wb3J0YW50IHdv\n" + "cmtsb2FkLCBuYW1lbHkgcmFuZG9tIEkvTy4NCkFkZGl0aW9uYWxseSwgdGhlIHBlcmZvcm1hbmNl\n" + "IGltcHJvdmVtZW50IGZvciBzZXF1ZW50aWFsIEkvTyB3YXMgYWNoaWV2ZWQNCmZvciBhbiB1bnJl\n" + "YWxpc3RpY2FsbHkgbG93IHF1ZXVlIGRlcHRoLiBTb3JyeSBidXQgZ2l2ZW4gdGhlc2UgbWVhc3Vy\n" + "ZW1lbnQNCnJlc3VsdHMgSSBkb24ndCBzZWUgd2h5IEkgc2hvdWxkIHNwZW5kIG1vcmUgdGltZSBv\n" + biB0aGlzIHBhdGNoIHNlcmllcy4NCg0KQmFydC4= -bc74ddf9c931252036d021b114dc610d80d99e8570e55984e0aef1be4e820ff4 +94e138d107f4fc1df4e1d497a71ce78f737d1afc386228e7df707af0ace130bc
diff --git a/a/1.txt b/N2/1.txt index d052aa1..249e71a 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -1,4 +1,4 @@ -On Wed, 2017-09-20 at 06:44 +0800, Ming Lei wrote: +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 diff --git a/a/content_digest b/N2/content_digest index 82b925b..3908dc9 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -9,25 +9,12 @@ "ref\0CACVXFVNvGna59hYG+gF7O41tKNURdbb+gm0sW-FGemnJi0RrRg@mail.gmail.com\0" "ref\01505846549.2671.52.camel@wdc.com\0" "ref\020170919224410.GA21829@ming.t460p\0" - "From\0Bart Van Assche <Bart.VanAssche@wdc.com>\0" - "Subject\0Re: [PATCH 1/5] block: don't call blk_mq_delay_run_hw_queue() in case of BLK_STS_RESOURCE\0" + "From\0Bart.VanAssche@wdc.com (Bart Van Assche)\0" + "Subject\0[PATCH 1/5] block: don't call blk_mq_delay_run_hw_queue() in case of BLK_STS_RESOURCE\0" "Date\0Tue, 19 Sep 2017 23:25:47 +0000\0" - "To\0ming.lei@redhat.com <ming.lei@redhat.com>\0" - "Cc\0linux-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>\0" "\00:1\0" "b\0" - "On Wed, 2017-09-20 at 06:44 +0800, Ming Lei wrote:\n" + "On Wed, 2017-09-20@06:44 +0800, Ming Lei wrote:\n" "> For this issue, it isn't same between SCSI and dm-rq.\n" "> \n" "> We don't need to run queue in .end_io of dm, and the theory is\n" @@ -54,4 +41,4 @@ "\n" Bart. -bc74ddf9c931252036d021b114dc610d80d99e8570e55984e0aef1be4e820ff4 +d7a4142c715fb8ecb39bd3edc27181286e99f345ecbbd0df56dfe33db39ad8d1
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.