From: Jan Kara <jack@suse.cz>
To: Yu Kuai <yukuai3@huawei.com>
Cc: jack@suse.cz, paolo.valente@linaro.org, axboe@kernel.dk,
tj@kernel.org, linux-block@vger.kernel.org,
cgroups@vger.kernel.org, linux-kernel@vger.kernel.org,
yi.zhang@huawei.com
Subject: Re: [PATCH -next 8/8] block, bfq: cleanup bfq_bfqq_handle_idle_busy_switch()
Date: Thu, 19 May 2022 13:23:09 +0200 [thread overview]
Message-ID: <20220519112309.nhbulnc5iz424ohl@quack3.lan> (raw)
In-Reply-To: <20220514090522.1669270-9-yukuai3@huawei.com>
On Sat 14-05-22 17:05:22, Yu Kuai wrote:
> 'wr_or_deserves_wr' is only used in bfq_update_bfqq_wr_on_rq_arrival(),
> which is only called from bfq_bfqq_handle_idle_busy_switch() in specific
> code branch, thus there is no need to precaculate 'wr_or_deserves_wr'
> each time bfq_bfqq_handle_idle_busy_switch() is called.
>
> Signed-off-by: Yu Kuai <yukuai3@huawei.com>
With this patch there's the same problem as with the previous one. Some of
the variables passed to bfq_update_bfqq_wr_on_rq_arrival() (in_burst,
soft_rt) would actually evaluate differently later in the function.
Honza
> ---
> block/bfq-iosched.c | 110 +++++++++++++++++++++++++-------------------
> 1 file changed, 62 insertions(+), 48 deletions(-)
>
> diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
> index 1e57d76c8dd3..cea8cb3f5ee2 100644
> --- a/block/bfq-iosched.c
> +++ b/block/bfq-iosched.c
> @@ -1624,15 +1624,65 @@ static unsigned long bfq_smallest_from_now(void)
> return jiffies - MAX_JIFFY_OFFSET;
> }
>
> +/*
> + * bfqq deserves to be weight-raised if:
> + * - it is sync,
> + * - it does not belong to a large burst,
> + * - it has been idle for enough time or is soft real-time,
> + * - is linked to a bfq_io_cq (it is not shared in any sense),
> + * - has a default weight (otherwise we assume the user wanted
> + * to control its weight explicitly)
> + *
> + * Merged bfq_queues are kept out of weight-raising
> + * (low-latency) mechanisms. The reason is that these queues
> + * are usually created for non-interactive and
> + * non-soft-real-time tasks. Yet this is not the case for
> + * stably-merged queues. These queues are merged just because
> + * they are created shortly after each other. So they may
> + * easily serve the I/O of an interactive or soft-real time
> + * application, if the application happens to spawn multiple
> + * processes. So let also stably-merged queued enjoy weight
> + * raising.
> + */
> +static bool bfqq_wr_or_deserves_wr(struct bfq_data *bfqd,
> + struct bfq_queue *bfqq,
> + struct request *rq,
> + bool interactive, bool soft_rt)
> +{
> + if (!bfqd->low_latency)
> + return false;
> +
> + if (bfqq->wr_coeff > 1)
> + return true;
> +
> + if (!bfq_bfqq_sync(bfqq))
> + return false;
> +
> + if (!bfqq->bic && !RQ_BIC(rq)->stably_merged)
> + return false;
> +
> + if (!interactive && !soft_rt)
> + return false;
> +
> + return true;
> +}
> +
> static void bfq_update_bfqq_wr_on_rq_arrival(struct bfq_data *bfqd,
> struct bfq_queue *bfqq,
> unsigned int old_wr_coeff,
> - bool wr_or_deserves_wr,
> - bool interactive,
> - bool in_burst,
> - bool soft_rt)
> -{
> - if (old_wr_coeff == 1 && wr_or_deserves_wr) {
> + struct request *rq,
> + bool interactive)
> +{
> + bool in_burst = bfq_bfqq_in_large_burst(bfqq);
> + bool soft_rt = bfqd->bfq_wr_max_softrt_rate > 0 &&
> + !BFQQ_TOTALLY_SEEKY(bfqq) &&
> + !in_burst &&
> + time_is_before_jiffies(bfqq->soft_rt_next_start) &&
> + bfqq->dispatched == 0 &&
> + bfqq->entity.new_weight == 40;
> +
> + if (old_wr_coeff == 1 &&
> + bfqq_wr_or_deserves_wr(bfqd, bfqq, rq, interactive, soft_rt)) {
> /* start a weight-raising period */
> if (interactive) {
> bfqq->service_from_wr = 0;
> @@ -1674,9 +1724,9 @@ static void bfq_update_bfqq_wr_on_rq_arrival(struct bfq_data *bfqd,
> if (interactive) { /* update wr coeff and duration */
> bfqq->wr_coeff = bfqd->bfq_wr_coeff;
> bfqq->wr_cur_max_time = bfq_wr_duration(bfqd);
> - } else if (in_burst)
> + } else if (in_burst) {
> bfqq->wr_coeff = 1;
> - else if (soft_rt) {
> + } else if (soft_rt) {
> /*
> * The application is now or still meeting the
> * requirements for being deemed soft rt. We
> @@ -1768,44 +1818,11 @@ static void bfq_bfqq_handle_idle_busy_switch(struct bfq_data *bfqd,
> struct request *rq,
> bool *interactive)
> {
> - bool soft_rt, in_burst, wr_or_deserves_wr,
> - idle_for_long_time = bfq_bfqq_idle_for_long_time(bfqd, bfqq);
> + bool in_burst = bfq_bfqq_in_large_burst(bfqq);
> + bool idle_for_long_time = bfq_bfqq_idle_for_long_time(bfqd, bfqq);
>
> - /*
> - * bfqq deserves to be weight-raised if:
> - * - it is sync,
> - * - it does not belong to a large burst,
> - * - it has been idle for enough time or is soft real-time,
> - * - is linked to a bfq_io_cq (it is not shared in any sense),
> - * - has a default weight (otherwise we assume the user wanted
> - * to control its weight explicitly)
> - */
> - in_burst = bfq_bfqq_in_large_burst(bfqq);
> - soft_rt = bfqd->bfq_wr_max_softrt_rate > 0 &&
> - !BFQQ_TOTALLY_SEEKY(bfqq) &&
> - !in_burst &&
> - time_is_before_jiffies(bfqq->soft_rt_next_start) &&
> - bfqq->dispatched == 0 &&
> - bfqq->entity.new_weight == 40;
> *interactive = !in_burst && idle_for_long_time &&
> bfqq->entity.new_weight == 40;
> - /*
> - * Merged bfq_queues are kept out of weight-raising
> - * (low-latency) mechanisms. The reason is that these queues
> - * are usually created for non-interactive and
> - * non-soft-real-time tasks. Yet this is not the case for
> - * stably-merged queues. These queues are merged just because
> - * they are created shortly after each other. So they may
> - * easily serve the I/O of an interactive or soft-real time
> - * application, if the application happens to spawn multiple
> - * processes. So let also stably-merged queued enjoy weight
> - * raising.
> - */
> - wr_or_deserves_wr = bfqd->low_latency &&
> - (bfqq->wr_coeff > 1 ||
> - (bfq_bfqq_sync(bfqq) &&
> - (bfqq->bic || RQ_BIC(rq)->stably_merged) &&
> - (*interactive || soft_rt)));
>
> /*
> * If bfqq happened to be activated in a burst, but has been
> @@ -1840,11 +1857,8 @@ static void bfq_bfqq_handle_idle_busy_switch(struct bfq_data *bfqd,
> if (time_is_before_jiffies(bfqq->split_time +
> bfqd->bfq_wr_min_idle_time)) {
> bfq_update_bfqq_wr_on_rq_arrival(bfqd, bfqq,
> - old_wr_coeff,
> - wr_or_deserves_wr,
> - *interactive,
> - in_burst,
> - soft_rt);
> + old_wr_coeff, rq,
> + *interactive);
>
> if (old_wr_coeff != bfqq->wr_coeff)
> bfqq->entity.prio_changed = 1;
> --
> 2.31.1
>
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
prev parent reply other threads:[~2022-05-19 11:23 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-14 9:05 [PATCH -next 0/8] multiple cleanup patches for bfq Yu Kuai
2022-05-14 9:05 ` [PATCH -next 1/8] block, bfq: cleanup bfq_weights_tree add/remove apis Yu Kuai
2022-05-19 10:59 ` Jan Kara
2022-05-14 9:05 ` [PATCH -next 2/8] block, bfq: cleanup __bfq_weights_tree_remove() Yu Kuai
2022-05-19 11:02 ` Jan Kara
2022-05-14 9:05 ` [PATCH -next 3/8] block, bfq: factor out code to update 'active_entities' Yu Kuai
2022-05-19 11:04 ` Jan Kara
2022-05-14 9:05 ` [PATCH -next 4/8] block, bfq: don't declare 'bfqd' as type 'void *' in bfq_group Yu Kuai
2022-05-19 11:01 ` Jan Kara
2022-05-14 9:05 ` [PATCH -next 5/8] block, bfq: cleanup bfq_activate_requeue_entity() Yu Kuai
2022-05-19 11:06 ` Jan Kara
2022-05-14 9:05 ` [PATCH -next 6/8] block, bfq: remove dead code for updating 'rq_in_driver' Yu Kuai
2022-05-19 11:06 ` Jan Kara
2022-05-14 9:05 ` [PATCH -next 7/8] block, bfq: cleanup bfq_bfqq_update_budg_for_activation() Yu Kuai
2022-05-19 11:18 ` Jan Kara
2022-05-19 13:21 ` yukuai (C)
2022-05-14 9:05 ` [PATCH -next 8/8] block, bfq: cleanup bfq_bfqq_handle_idle_busy_switch() Yu Kuai
2022-05-19 11:23 ` Jan Kara [this message]
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=20220519112309.nhbulnc5iz424ohl@quack3.lan \
--to=jack@suse.cz \
--cc=axboe@kernel.dk \
--cc=cgroups@vger.kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=paolo.valente@linaro.org \
--cc=tj@kernel.org \
--cc=yi.zhang@huawei.com \
--cc=yukuai3@huawei.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox