diff for duplicates of <1482428377.2682.13.camel@sandisk.com> diff --git a/a/1.txt b/N1/1.txt index f051a47..834e474 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,24 +1,27 @@ -T24gVGh1LCAyMDE2LTEyLTIyIGF0IDA5OjEyIC0wODAwLCBPbWFyIFNhbmRvdmFsIHdyb3RlOg0K -PiBPbiBUaHUsIERlYyAyMiwgMjAxNiBhdCAwNDo1NzozNlBNICswMDAwLCBCYXJ0IFZhbiBBc3Nj -aGUgd3JvdGU6DQo+ID4gT24gVGh1LCAyMDE2LTEyLTIyIGF0IDA4OjUyIC0wODAwLCBPbWFyIFNh -bmRvdmFsIHdyb3RlOg0KPiA+ID4gVGhpcyBhcHByb2FjaCBvY2N1cnJlZCB0byB1cywgYnV0IHdl -IGNvdWxkbid0IGZpZ3VyZSBvdXQgYSB3YXkgdG8gbWFrZQ0KPiA+ID4gYmxrX21xX3RhZ190b19y -cSgpIHdvcmsgd2l0aCBpdC4gRnJvbSBza2ltbWluZyBvdmVyIHRoZSBwYXRjaGVzLCBJDQo+ID4g -PiBkaWRuJ3Qgc2VlIGEgc29sdXRpb24gdG8gdGhhdCBwcm9ibGVtLg0KPiA+IA0KPiA+IENhbiB5 -b3UgY2xhcmlmeSB5b3VyIGNvbW1lbnQ/IFNpbmNlIG15IHBhdGNoZXMgaW5pdGlhbGl6ZSBib3Ro -IHRhZ3MtPnJxc1tdDQo+ID4gYW5kIHNjaGVkX3RhZ3MtPnJxc1tdIHRoZSBmdW5jdGlvbiBibGtf -bXFfdGFnX3RvX3JxKCkgc2hvdWxkIHN0aWxsIHdvcmsuDQo+IA0KPiBTb3JyeSwgeW91J3JlIHJp -Z2h0LCBpdCBkb2VzIHdvcmssIGJ1dCB0YWdzLT5ycXNbXSBlbmRzIHVwIGJlaW5nIHRoZQ0KPiBl -eHRyYSBsb29rdXAgdGFibGUuIEkgc3VzcGVjdCB0aGF0IHRoZSBydW50aW1lIG92ZXJoZWFkIG9m -IGtlZXBpbmcgdGhhdA0KPiB1cCB0byBkYXRlIGNvdWxkIGJlIHdvcnNlIHRoYW4gY29weWluZyB0 -aGUgcnEgZmllbGRzIGlmIHlvdSBoYXZlIGxvdHMgb2YNCj4gQ1BVcyBidXQgb25seSBvbmUgaGFy -ZHdhcmUgcXVldWUuDQoNCkhlbGxvIE9tYXIsDQoNCkknbSBub3Qgc3VyZSB0aGF0IGFueXRoaW5n -IGNhbiBiZSBkb25lIGlmIHRoZSBudW1iZXIgb2YgQ1BVcyB0aGF0IGlzIHN1Ym1pdHRpbmcNCkkv -TyBpcyBsYXJnZSBjb21wYXJlZCB0byB0aGUgcXVldWUgZGVwdGggc28gSSBkb24ndCB0aGluayB3 -ZSBzaG91bGQgc3BlbmQgb3VyDQp0aW1lIG9uIHRoYXQgY2FzZS4gSWYgdGhlIHF1ZXVlIGRlcHRo -IGlzIGxhcmdlIGVub3VnaCB0aGVuIHRoZSBzYml0bWFwIGNvZGUgd2lsbA0KYWxsb2NhdGUgdGFn -cyBzdWNoIHRoYXQgZGlmZmVyZW50IENQVXMgdXNlIGRpZmZlcmVudCBycXNbXSBlbGVtZW50cy4N -Cg0KVGhlIGFkdmFudGFnZXMgb2YgdGhlIGFwcHJvYWNoIEkgcHJvcG9zZWQgYXJlIHN1Y2ggdGhh -dCBJIGFtIGNvbnZpbmNlZCB0aGF0IGlzDQp3aGF0IHdlIHNob3VsZCBzdGFydCBmcm9tIGFuZCBh -ZGRyZXNzIGNvbnRlbnRpb24gb24gdGhlIHRhZ3MtPnJxc1tdIGFycmF5IGlmIGl0DQptZWFzdXJl -bWVudHMgc2hvdyB0aGF0IGl0IGlzIG5lY2Vzc2FyeSB0byBhZGRyZXNzIGl0Lg0KDQpCYXJ0Lg== +On Thu, 2016-12-22 at 09:12 -0800, Omar Sandoval wrote: +> On Thu, Dec 22, 2016 at 04:57:36PM +0000, Bart Van Assche wrote: +> > On Thu, 2016-12-22 at 08:52 -0800, Omar Sandoval wrote: +> > > This approach occurred to us, but we couldn't figure out a way to make +> > > blk_mq_tag_to_rq() work with it. From skimming over the patches, I +> > > didn't see a solution to that problem. +> > +> > Can you clarify your comment? Since my patches initialize both tags->rqs[] +> > and sched_tags->rqs[] the function blk_mq_tag_to_rq() should still work. +> +> Sorry, you're right, it does work, but tags->rqs[] ends up being the +> extra lookup table. I suspect that the runtime overhead of keeping that +> up to date could be worse than copying the rq fields if you have lots of +> CPUs but only one hardware queue. + +Hello Omar, + +I'm not sure that anything can be done if the number of CPUs that is submitting +I/O is large compared to the queue depth so I don't think we should spend our +time on that case. If the queue depth is large enough then the sbitmap code will +allocate tags such that different CPUs use different rqs[] elements. + +The advantages of the approach I proposed are such that I am convinced that is +what we should start from and address contention on the tags->rqs[] array if it +measurements show that it is necessary to address it. + +Bart. diff --git a/a/content_digest b/N1/content_digest index c91af27..ed79444 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -15,29 +15,32 @@ " paolo.valente@linaro.org <paolo.valente@linaro.org>\0" "\00:1\0" "b\0" - "T24gVGh1LCAyMDE2LTEyLTIyIGF0IDA5OjEyIC0wODAwLCBPbWFyIFNhbmRvdmFsIHdyb3RlOg0K\n" - "PiBPbiBUaHUsIERlYyAyMiwgMjAxNiBhdCAwNDo1NzozNlBNICswMDAwLCBCYXJ0IFZhbiBBc3Nj\n" - "aGUgd3JvdGU6DQo+ID4gT24gVGh1LCAyMDE2LTEyLTIyIGF0IDA4OjUyIC0wODAwLCBPbWFyIFNh\n" - "bmRvdmFsIHdyb3RlOg0KPiA+ID4gVGhpcyBhcHByb2FjaCBvY2N1cnJlZCB0byB1cywgYnV0IHdl\n" - "IGNvdWxkbid0IGZpZ3VyZSBvdXQgYSB3YXkgdG8gbWFrZQ0KPiA+ID4gYmxrX21xX3RhZ190b19y\n" - "cSgpIHdvcmsgd2l0aCBpdC4gRnJvbSBza2ltbWluZyBvdmVyIHRoZSBwYXRjaGVzLCBJDQo+ID4g\n" - "PiBkaWRuJ3Qgc2VlIGEgc29sdXRpb24gdG8gdGhhdCBwcm9ibGVtLg0KPiA+IA0KPiA+IENhbiB5\n" - "b3UgY2xhcmlmeSB5b3VyIGNvbW1lbnQ/IFNpbmNlIG15IHBhdGNoZXMgaW5pdGlhbGl6ZSBib3Ro\n" - "IHRhZ3MtPnJxc1tdDQo+ID4gYW5kIHNjaGVkX3RhZ3MtPnJxc1tdIHRoZSBmdW5jdGlvbiBibGtf\n" - "bXFfdGFnX3RvX3JxKCkgc2hvdWxkIHN0aWxsIHdvcmsuDQo+IA0KPiBTb3JyeSwgeW91J3JlIHJp\n" - "Z2h0LCBpdCBkb2VzIHdvcmssIGJ1dCB0YWdzLT5ycXNbXSBlbmRzIHVwIGJlaW5nIHRoZQ0KPiBl\n" - "eHRyYSBsb29rdXAgdGFibGUuIEkgc3VzcGVjdCB0aGF0IHRoZSBydW50aW1lIG92ZXJoZWFkIG9m\n" - "IGtlZXBpbmcgdGhhdA0KPiB1cCB0byBkYXRlIGNvdWxkIGJlIHdvcnNlIHRoYW4gY29weWluZyB0\n" - "aGUgcnEgZmllbGRzIGlmIHlvdSBoYXZlIGxvdHMgb2YNCj4gQ1BVcyBidXQgb25seSBvbmUgaGFy\n" - "ZHdhcmUgcXVldWUuDQoNCkhlbGxvIE9tYXIsDQoNCkknbSBub3Qgc3VyZSB0aGF0IGFueXRoaW5n\n" - "IGNhbiBiZSBkb25lIGlmIHRoZSBudW1iZXIgb2YgQ1BVcyB0aGF0IGlzIHN1Ym1pdHRpbmcNCkkv\n" - "TyBpcyBsYXJnZSBjb21wYXJlZCB0byB0aGUgcXVldWUgZGVwdGggc28gSSBkb24ndCB0aGluayB3\n" - "ZSBzaG91bGQgc3BlbmQgb3VyDQp0aW1lIG9uIHRoYXQgY2FzZS4gSWYgdGhlIHF1ZXVlIGRlcHRo\n" - "IGlzIGxhcmdlIGVub3VnaCB0aGVuIHRoZSBzYml0bWFwIGNvZGUgd2lsbA0KYWxsb2NhdGUgdGFn\n" - "cyBzdWNoIHRoYXQgZGlmZmVyZW50IENQVXMgdXNlIGRpZmZlcmVudCBycXNbXSBlbGVtZW50cy4N\n" - "Cg0KVGhlIGFkdmFudGFnZXMgb2YgdGhlIGFwcHJvYWNoIEkgcHJvcG9zZWQgYXJlIHN1Y2ggdGhh\n" - "dCBJIGFtIGNvbnZpbmNlZCB0aGF0IGlzDQp3aGF0IHdlIHNob3VsZCBzdGFydCBmcm9tIGFuZCBh\n" - "ZGRyZXNzIGNvbnRlbnRpb24gb24gdGhlIHRhZ3MtPnJxc1tdIGFycmF5IGlmIGl0DQptZWFzdXJl\n" - bWVudHMgc2hvdyB0aGF0IGl0IGlzIG5lY2Vzc2FyeSB0byBhZGRyZXNzIGl0Lg0KDQpCYXJ0Lg== + "On Thu, 2016-12-22 at 09:12 -0800, Omar Sandoval wrote:\n" + "> On Thu, Dec 22, 2016 at 04:57:36PM +0000, Bart Van Assche wrote:\n" + "> > On Thu, 2016-12-22 at 08:52 -0800, Omar Sandoval wrote:\n" + "> > > This approach occurred to us, but we couldn't figure out a way to make\n" + "> > > blk_mq_tag_to_rq() work with it. From skimming over the patches, I\n" + "> > > didn't see a solution to that problem.\n" + "> > \n" + "> > Can you clarify your comment? Since my patches initialize both tags->rqs[]\n" + "> > and sched_tags->rqs[] the function blk_mq_tag_to_rq() should still work.\n" + "> \n" + "> Sorry, you're right, it does work, but tags->rqs[] ends up being the\n" + "> extra lookup table. I suspect that the runtime overhead of keeping that\n" + "> up to date could be worse than copying the rq fields if you have lots of\n" + "> CPUs but only one hardware queue.\n" + "\n" + "Hello Omar,\n" + "\n" + "I'm not sure that anything can be done if the number of CPUs that is submitting\n" + "I/O is large compared to the queue depth so I don't think we should spend our\n" + "time on that case. If the queue depth is large enough then the sbitmap code will\n" + "allocate tags such that different CPUs use different rqs[] elements.\n" + "\n" + "The advantages of the approach I proposed are such that I am convinced that is\n" + "what we should start from and address contention on the tags->rqs[] array if it\n" + "measurements show that it is necessary to address it.\n" + "\n" + Bart. -f37592859b2947da98d696efc9eb9b688e1260816541dfcbc89e0248a531c25e +bd0c8cb769bad09891010d267cafb5ae8ff49eb8859f1fbfc2a44c86d0c82219
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.