diff for duplicates of <2155485.5RQgH7pnPy@natalenko.name> diff --git a/a/1.txt b/N1/1.txt index 5175899..6c8787c 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,13 +1,13 @@ Hi. -On =C4=8Dtvrtek 28. prosince 2017 12:19:17 CET Paolo Valente wrote: +On čtvrtek 28. prosince 2017 12:19:17 CET Paolo Valente wrote: > To maximise responsiveness, BFQ raises the weight, and performs device > idling, for bfq_queues associated with processes deemed as > interactive. In particular, weight raising has a maximum duration, > equal to the time needed to start a large application. If a > weight-raised process goes on doing I/O beyond this maximum duration, > it loses weight-raising. ->=20 +> > This mechanism is evidently vulnerable to the following false > positives: I/O-bound applications that will go on doing I/O for much > longer than the duration of weight-raising. These applications have @@ -19,7 +19,7 @@ On =C4=8Dtvrtek 28. prosince 2017 12:19:17 CET Paolo Valente wrote: > b) make BFQ uselessly perform device idling; device idling results > in loss of device throughput with most flash-based storage, and may > increase latencies when used purposelessly. ->=20 +> > This commit adds a countermeasure to reduce both the above > problems. To introduce this countermeasure, we provide the following > extra piece of information (full details in the comments added by this @@ -28,7 +28,7 @@ On =C4=8Dtvrtek 28. prosince 2017 12:19:17 CET Paolo Valente wrote: > transfer at most ~110K sectors each. Accordingly, a process initially > deemed as interactive has no right to be weight-raised any longer, > once transferred 110K sectors or more. ->=20 +> > Basing on this consideration, this commit early-ends weight-raising > for a bfq_queue if the latter happens to have received an amount of > service at least equal to 110K sectors (actually, a little bit more, @@ -37,34 +37,31 @@ On =C4=8Dtvrtek 28. prosince 2017 12:19:17 CET Paolo Valente wrote: > allowed weight-raising period finishes. Thus this early ending of > weight-raising reduces the amount of time during which these > applications cause the problems described above. ->=20 +> > Signed-off-by: Paolo Valente <paolo.valente@linaro.org> > --- > block/bfq-iosched.c | 81 -> +++++++++++++++++++++++++++++++++++++++++++++++------ block/bfq-iosched.h= - | +> +++++++++++++++++++++++++++++++++++++++++++++++------ block/bfq-iosched.h | > 5 ++++ > block/bfq-wf2q.c | 3 ++ > 3 files changed, 80 insertions(+), 9 deletions(-) ->=20 +> > diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c > index 6f75015d18c0..ea48b5c8f088 100644 > --- a/block/bfq-iosched.c > +++ b/block/bfq-iosched.c > @@ -209,15 +209,17 @@ static struct kmem_cache *bfq_pool; > * interactive applications automatically, using the following formula: -> * duration =3D (R / r) * T, where r is the peak rate of the device, and +> * duration = (R / r) * T, where r is the peak rate of the device, and > * R and T are two reference parameters. > - * In particular, R is the peak rate of the reference device (see below), > - * and T is a reference time: given the systems that are likely to be > - * installed on the reference device according to its speed class, T is -> - * about the maximum time needed, under BFQ and while reading two files = -in +> - * about the maximum time needed, under BFQ and while reading two files in > - * parallel, to load typical large applications on these systems. > - * In practice, the slower/faster the device at hand is, the more/less it > - * takes to load applications with respect to the reference device. -> - * Accordingly, the longer/shorter BFQ grants weight raising to interact= -ive +> - * Accordingly, the longer/shorter BFQ grants weight raising to interactive > - * applications. > + * In particular, R is the peak rate of the reference device (see > + * below), and T is a reference time: given the systems that are @@ -83,7 +80,7 @@ ive > @@ -254,6 +256,60 @@ static int T_slow[2]; > static int T_fast[2]; > static int device_speed_thresh[2]; ->=20 +> > +/* > + * BFQ uses the above-detailed, time-based weight-raising mechanism to > + * privilege interactive tasks. This mechanism is vulnerable to the @@ -136,26 +133,25 @@ ive > + * during which interactive false positives cause the two problems > + * described at the beginning of these comments. > + */ -> +static const unsigned long max_service_from_wr =3D 120000; +> +static const unsigned long max_service_from_wr = 120000; > + > #define RQ_BIC(rq) icq_to_bic((rq)->elv.priv[0]) > #define RQ_BFQQ(rq) ((rq)->elv.priv[1]) ->=20 +> > @@ -1352,6 +1408,7 @@ static void bfq_update_bfqq_wr_on_rq_arrival(struct -> bfq_data *bfqd, if (old_wr_coeff =3D=3D 1 && wr_or_deserves_wr) { +> bfq_data *bfqd, if (old_wr_coeff == 1 && wr_or_deserves_wr) { > /* start a weight-raising period */ > if (interactive) { -> + bfqq->service_from_wr =3D 0; -> bfqq->wr_coeff =3D bfqd->bfq_wr_coeff; -> bfqq->wr_cur_max_time =3D bfq_wr_duration(bfqd); +> + bfqq->service_from_wr = 0; +> bfqq->wr_coeff = bfqd->bfq_wr_coeff; +> bfqq->wr_cur_max_time = bfq_wr_duration(bfqd); > } else { -> @@ -3665,6 +3722,12 @@ static void bfq_update_wr_data(struct bfq_data *bf= -qd, -> struct bfq_queue *bfqq) bfqq->entity.prio_changed =3D 1; +> @@ -3665,6 +3722,12 @@ static void bfq_update_wr_data(struct bfq_data *bfqd, +> struct bfq_queue *bfqq) bfqq->entity.prio_changed = 1; > } > } > + if (bfqq->wr_coeff > 1 && -> + bfqq->wr_cur_max_time !=3D bfqd->bfq_wr_rt_max_time && +> + bfqq->wr_cur_max_time != bfqd->bfq_wr_rt_max_time && > + bfqq->service_from_wr > max_service_from_wr) { > + /* see comments on max_service_from_wr */ > + bfq_bfqq_end_wr(bfqq); @@ -176,27 +172,25 @@ qd, > + * last transition to weight-raised state. > + */ > + unsigned long service_from_wr; ->=20 +> > /* > * Value of wr start time when switching to soft rt > diff --git a/block/bfq-wf2q.c b/block/bfq-wf2q.c > index 4456eda34e48..4498c43245e2 100644 > --- a/block/bfq-wf2q.c > +++ b/block/bfq-wf2q.c -> @@ -838,6 +838,9 @@ void bfq_bfqq_served(struct bfq_queue *bfqq, int serv= -ed) +> @@ -838,6 +838,9 @@ void bfq_bfqq_served(struct bfq_queue *bfqq, int served) > if (!bfqq->service_from_backlogged) -> bfqq->first_IO_time =3D jiffies; ->=20 +> bfqq->first_IO_time = jiffies; +> > + if (bfqq->wr_coeff > 1) -> + bfqq->service_from_wr +=3D served; +> + bfqq->service_from_wr += served; > + -> bfqq->service_from_backlogged +=3D served; +> bfqq->service_from_backlogged += served; > for_each_entity(entity) { -> st =3D bfq_entity_service_tree(entity); +> st = bfq_entity_service_tree(entity); -Building and running it routinely on my laptop didn't reveal any smoke (at= -=20 +Building and running it routinely on my laptop didn't reveal any smoke (at least, yet), so Tested-by: Oleksandr Natalenko <oleksandr@natalenko.name> diff --git a/a/content_digest b/N1/content_digest index eff9d62..06db498 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -14,14 +14,14 @@ "b\0" "Hi.\n" "\n" - "On =C4=8Dtvrtek 28. prosince 2017 12:19:17 CET Paolo Valente wrote:\n" + "On \304\215tvrtek 28. prosince 2017 12:19:17 CET Paolo Valente wrote:\n" "> To maximise responsiveness, BFQ raises the weight, and performs device\n" "> idling, for bfq_queues associated with processes deemed as\n" "> interactive. In particular, weight raising has a maximum duration,\n" "> equal to the time needed to start a large application. If a\n" "> weight-raised process goes on doing I/O beyond this maximum duration,\n" "> it loses weight-raising.\n" - ">=20\n" + "> \n" "> This mechanism is evidently vulnerable to the following false\n" "> positives: I/O-bound applications that will go on doing I/O for much\n" "> longer than the duration of weight-raising. These applications have\n" @@ -33,7 +33,7 @@ "> b) make BFQ uselessly perform device idling; device idling results\n" "> in loss of device throughput with most flash-based storage, and may\n" "> increase latencies when used purposelessly.\n" - ">=20\n" + "> \n" "> This commit adds a countermeasure to reduce both the above\n" "> problems. To introduce this countermeasure, we provide the following\n" "> extra piece of information (full details in the comments added by this\n" @@ -42,7 +42,7 @@ "> transfer at most ~110K sectors each. Accordingly, a process initially\n" "> deemed as interactive has no right to be weight-raised any longer,\n" "> once transferred 110K sectors or more.\n" - ">=20\n" + "> \n" "> Basing on this consideration, this commit early-ends weight-raising\n" "> for a bfq_queue if the latter happens to have received an amount of\n" "> service at least equal to 110K sectors (actually, a little bit more,\n" @@ -51,34 +51,31 @@ "> allowed weight-raising period finishes. Thus this early ending of\n" "> weight-raising reduces the amount of time during which these\n" "> applications cause the problems described above.\n" - ">=20\n" + "> \n" "> Signed-off-by: Paolo Valente <paolo.valente@linaro.org>\n" "> ---\n" "> block/bfq-iosched.c | 81\n" - "> +++++++++++++++++++++++++++++++++++++++++++++++------ block/bfq-iosched.h=\n" - " |\n" + "> +++++++++++++++++++++++++++++++++++++++++++++++------ block/bfq-iosched.h |\n" "> 5 ++++\n" "> block/bfq-wf2q.c | 3 ++\n" "> 3 files changed, 80 insertions(+), 9 deletions(-)\n" - ">=20\n" + "> \n" "> diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c\n" "> index 6f75015d18c0..ea48b5c8f088 100644\n" "> --- a/block/bfq-iosched.c\n" "> +++ b/block/bfq-iosched.c\n" "> @@ -209,15 +209,17 @@ static struct kmem_cache *bfq_pool;\n" "> * interactive applications automatically, using the following formula:\n" - "> * duration =3D (R / r) * T, where r is the peak rate of the device, and\n" + "> * duration = (R / r) * T, where r is the peak rate of the device, and\n" "> * R and T are two reference parameters.\n" "> - * In particular, R is the peak rate of the reference device (see below),\n" "> - * and T is a reference time: given the systems that are likely to be\n" "> - * installed on the reference device according to its speed class, T is\n" - "> - * about the maximum time needed, under BFQ and while reading two files =\n" - "in\n" + "> - * about the maximum time needed, under BFQ and while reading two files in\n" "> - * parallel, to load typical large applications on these systems.\n" "> - * In practice, the slower/faster the device at hand is, the more/less it\n" "> - * takes to load applications with respect to the reference device.\n" - "> - * Accordingly, the longer/shorter BFQ grants weight raising to interact=\n" - "ive\n" + "> - * Accordingly, the longer/shorter BFQ grants weight raising to interactive\n" "> - * applications.\n" "> + * In particular, R is the peak rate of the reference device (see\n" "> + * below), and T is a reference time: given the systems that are\n" @@ -97,7 +94,7 @@ "> @@ -254,6 +256,60 @@ static int T_slow[2];\n" "> static int T_fast[2];\n" "> static int device_speed_thresh[2];\n" - ">=20\n" + "> \n" "> +/*\n" "> + * BFQ uses the above-detailed, time-based weight-raising mechanism to\n" "> + * privilege interactive tasks. This mechanism is vulnerable to the\n" @@ -150,26 +147,25 @@ "> + * during which interactive false positives cause the two problems\n" "> + * described at the beginning of these comments.\n" "> + */\n" - "> +static const unsigned long max_service_from_wr =3D 120000;\n" + "> +static const unsigned long max_service_from_wr = 120000;\n" "> +\n" "> #define RQ_BIC(rq)\t\ticq_to_bic((rq)->elv.priv[0])\n" "> #define RQ_BFQQ(rq)\t\t((rq)->elv.priv[1])\n" - ">=20\n" + "> \n" "> @@ -1352,6 +1408,7 @@ static void bfq_update_bfqq_wr_on_rq_arrival(struct\n" - "> bfq_data *bfqd, if (old_wr_coeff =3D=3D 1 && wr_or_deserves_wr) {\n" + "> bfq_data *bfqd, if (old_wr_coeff == 1 && wr_or_deserves_wr) {\n" "> \t\t/* start a weight-raising period */\n" "> \t\tif (interactive) {\n" - "> +\t\t\tbfqq->service_from_wr =3D 0;\n" - "> \t\t\tbfqq->wr_coeff =3D bfqd->bfq_wr_coeff;\n" - "> \t\t\tbfqq->wr_cur_max_time =3D bfq_wr_duration(bfqd);\n" + "> +\t\t\tbfqq->service_from_wr = 0;\n" + "> \t\t\tbfqq->wr_coeff = bfqd->bfq_wr_coeff;\n" + "> \t\t\tbfqq->wr_cur_max_time = bfq_wr_duration(bfqd);\n" "> \t\t} else {\n" - "> @@ -3665,6 +3722,12 @@ static void bfq_update_wr_data(struct bfq_data *bf=\n" - "qd,\n" - "> struct bfq_queue *bfqq) bfqq->entity.prio_changed =3D 1;\n" + "> @@ -3665,6 +3722,12 @@ static void bfq_update_wr_data(struct bfq_data *bfqd,\n" + "> struct bfq_queue *bfqq) bfqq->entity.prio_changed = 1;\n" "> \t\t\t}\n" "> \t\t}\n" "> +\t\tif (bfqq->wr_coeff > 1 &&\n" - "> +\t\t bfqq->wr_cur_max_time !=3D bfqd->bfq_wr_rt_max_time &&\n" + "> +\t\t bfqq->wr_cur_max_time != bfqd->bfq_wr_rt_max_time &&\n" "> +\t\t bfqq->service_from_wr > max_service_from_wr) {\n" "> +\t\t\t/* see comments on max_service_from_wr */\n" "> +\t\t\tbfq_bfqq_end_wr(bfqq);\n" @@ -190,27 +186,25 @@ "> +\t * last transition to weight-raised state.\n" "> +\t */\n" "> +\tunsigned long service_from_wr;\n" - ">=20\n" + "> \n" "> \t/*\n" "> \t * Value of wr start time when switching to soft rt\n" "> diff --git a/block/bfq-wf2q.c b/block/bfq-wf2q.c\n" "> index 4456eda34e48..4498c43245e2 100644\n" "> --- a/block/bfq-wf2q.c\n" "> +++ b/block/bfq-wf2q.c\n" - "> @@ -838,6 +838,9 @@ void bfq_bfqq_served(struct bfq_queue *bfqq, int serv=\n" - "ed)\n" + "> @@ -838,6 +838,9 @@ void bfq_bfqq_served(struct bfq_queue *bfqq, int served)\n" "> if (!bfqq->service_from_backlogged)\n" - "> \t\tbfqq->first_IO_time =3D jiffies;\n" - ">=20\n" + "> \t\tbfqq->first_IO_time = jiffies;\n" + "> \n" "> +\tif (bfqq->wr_coeff > 1)\n" - "> +\t\tbfqq->service_from_wr +=3D served;\n" + "> +\t\tbfqq->service_from_wr += served;\n" "> +\n" - "> \tbfqq->service_from_backlogged +=3D served;\n" + "> \tbfqq->service_from_backlogged += served;\n" "> \tfor_each_entity(entity) {\n" - "> \t\tst =3D bfq_entity_service_tree(entity);\n" + "> \t\tst = bfq_entity_service_tree(entity);\n" "\n" - "Building and running it routinely on my laptop didn't reveal any smoke (at=\n" - "=20\n" + "Building and running it routinely on my laptop didn't reveal any smoke (at \n" "least, yet), so\n" "\n" "Tested-by: Oleksandr Natalenko <oleksandr@natalenko.name>\n" @@ -220,4 +214,4 @@ "Regards,\n" Oleksandr -673166371c2577290d6458f468bcdb2d172438c2b12df73b876fe5f6e13618d2 +d93db59bf4ca2e117563f3278d47a6e8b7a415efea1c4693d7b53d4649c2cfa7
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.