diff for duplicates of <1489509154.2676.6.camel@sandisk.com> diff --git a/a/1.txt b/N1/1.txt index 3d69a26..7c429bf 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,7 +1,6 @@ On Tue, 2017-03-14 at 16:35 +0100, Paolo Valente wrote: -> > Il giorno 07 mar 2017, alle ore 02:00, Bart Van Assche <bart.vanassche@= -sandisk.com> ha scritto: -> >=20 +> > Il giorno 07 mar 2017, alle ore 02:00, Bart Van Assche <bart.vanassche@sandisk.com> ha scritto: +> > > > Additionally, the complexity of the code is huge. Just like for CFQ, > > sooner or later someone will run into a bug or a performance issue > > and will post a patch to fix it. However, the complexity of BFQ is @@ -9,7 +8,7 @@ sandisk.com> ha scritto: > > whether or not such a patch negatively affects a workload or device > > that has not been tested by the author of the patch. This makes me > > wonder what process should be followed to verify future BFQ patches? ->=20 +> > Third and last, a proposal: why don't we discuss this issue at LSF > too? In particular, we could talk about the parts of BFQ that seem > more complex to understand, until they become clearer to you. Then I @@ -31,16 +30,13 @@ static int bfq_min_budget(struct bfq_data *bfqd) } How to predict the performance impact of any changes in e.g. this function? -It is really great that a performance benchmark is available. But what shou= -ld +It is really great that a performance benchmark is available. But what should a developer do who only has access to a small subset of all the storage -devices that are supported by the Linux kernel and hence who can not run th= -e +devices that are supported by the Linux kernel and hence who can not run the benchmark against every supported storage device? Do developers who do not fully understand the BFQ algorithms and who run into a performance problem -have any other option than trial and error for fixing such performance issu= -es? +have any other option than trial and error for fixing such performance issues? Thanks, -Bart.= +Bart. diff --git a/a/content_digest b/N1/content_digest index 8574ed0..522f5c4 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -17,9 +17,8 @@ "\00:1\0" "b\0" "On Tue, 2017-03-14 at 16:35 +0100, Paolo Valente wrote:\n" - "> > Il giorno 07 mar 2017, alle ore 02:00, Bart Van Assche <bart.vanassche@=\n" - "sandisk.com> ha scritto:\n" - "> >=20\n" + "> > Il giorno 07 mar 2017, alle ore 02:00, Bart Van Assche <bart.vanassche@sandisk.com> ha scritto:\n" + "> > \n" "> > Additionally, the complexity of the code is huge. Just like for CFQ,\n" "> > sooner or later someone will run into a bug or a performance issue\n" "> > and will post a patch to fix it. However, the complexity of BFQ is\n" @@ -27,7 +26,7 @@ "> > whether or not such a patch negatively affects a workload or device\n" "> > that has not been tested by the author of the patch. This makes me\n" "> > wonder what process should be followed to verify future BFQ patches?\n" - ">=20\n" + "> \n" "> Third and last, a proposal: why don't we discuss this issue at LSF\n" "> too? In particular, we could talk about the parts of BFQ that seem\n" "> more complex to understand, until they become clearer to you. Then I\n" @@ -49,18 +48,15 @@ "}\n" "\n" "How to predict the performance impact of any changes in e.g. this function?\n" - "It is really great that a performance benchmark is available. But what shou=\n" - "ld\n" + "It is really great that a performance benchmark is available. But what should\n" "a developer do who only has access to a small subset of all the storage\n" - "devices that are supported by the Linux kernel and hence who can not run th=\n" - "e\n" + "devices that are supported by the Linux kernel and hence who can not run the\n" "benchmark against every supported storage device? Do developers who do not\n" "fully understand the BFQ algorithms and who run into a performance problem\n" - "have any other option than trial and error for fixing such performance issu=\n" - "es?\n" + "have any other option than trial and error for fixing such performance issues?\n" "\n" "Thanks,\n" "\n" - Bart.= + Bart. -dd63dda2f4359d3073719036fc562669018bdf57a5735ab9a5b428ca66f11beb +249c50545c26435555db03491edbe1c8eb3b54f60798938a1f0d4f0335548441
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.