Linux block layer
 help / color / mirror / Atom feed
From: Ming Lei <ming.lei@redhat.com>
To: Zizhi Wo <wozizhi@huawei.com>
Cc: axboe@kernel.dk, linux-block@vger.kernel.org,
	yangerkun@huawei.com, yukuai3@huawei.com, tj@kernel.org
Subject: Re: [PATCH 1/3] blk-throttle: Fix wrong tg->[bytes/io]_disp update in __tg_update_carryover()
Date: Thu, 17 Apr 2025 10:27:16 +0800	[thread overview]
Message-ID: <aABnBBp4ZZ6pQAOM@fedora> (raw)
In-Reply-To: <20250417015033.512940-2-wozizhi@huawei.com>

On Thu, Apr 17, 2025 at 09:50:31AM +0800, Zizhi Wo wrote:
> In commit 6cc477c36875 ("blk-throttle: carry over directly"), the carryover
> bytes/ios was be carried to [bytes/io]_disp. However, its update mechanism
> has some issues.
> 
> In __tg_update_carryover(), we calculate "bytes" and "ios" to represent the
> carryover, but the computation when updating [bytes/io]_disp is incorrect.
> This patch fixes the issue.
> 
> And if the bps/iops limit was previously set to max and later changed to a
> smaller value, we may not update tg->[bytes/io]_disp to 0 in
> tg_update_carryover(). Relying solely on throtl_trim_slice() is not
> sufficient, which can lead to subsequent bio dispatches not behaving as
> expected. We should set tg->[bytes/io]_disp to 0 in non_carryover case.
> The same handling applies when nr_queued is 0.
> 
> Fixes: 6cc477c36875 ("blk-throttle: carry over directly")
> Signed-off-by: Zizhi Wo <wozizhi@huawei.com>
> ---
>  block/blk-throttle.c | 33 +++++++++++++++++++++++++--------
>  1 file changed, 25 insertions(+), 8 deletions(-)
> 
> diff --git a/block/blk-throttle.c b/block/blk-throttle.c
> index 91dab43c65ab..df9825eb83be 100644
> --- a/block/blk-throttle.c
> +++ b/block/blk-throttle.c
> @@ -644,20 +644,39 @@ static void __tg_update_carryover(struct throtl_grp *tg, bool rw,
>  	u64 bps_limit = tg_bps_limit(tg, rw);
>  	u32 iops_limit = tg_iops_limit(tg, rw);
>  
> +	/*
> +	 * If the queue is empty, carryover handling is not needed. In such cases,
> +	 * tg->[bytes/io]_disp should be reset to 0 to avoid impacting the dispatch
> +	 * of subsequent bios. The same handling applies when the previous BPS/IOPS
> +	 * limit was set to max.
> +	 */
> +	if (tg->service_queue.nr_queued[rw] == 0) {
> +		tg->bytes_disp[rw] = 0;
> +		tg->io_disp[rw] = 0;
> +		return;
> +	}
> +
>  	/*
>  	 * If config is updated while bios are still throttled, calculate and
>  	 * accumulate how many bytes/ios are waited across changes. And
>  	 * carryover_bytes/ios will be used to calculate new wait time under new
>  	 * configuration.
>  	 */
> -	if (bps_limit != U64_MAX)
> +	if (bps_limit != U64_MAX) {
>  		*bytes = calculate_bytes_allowed(bps_limit, jiffy_elapsed) -
>  			tg->bytes_disp[rw];
> -	if (iops_limit != UINT_MAX)
> +		tg->bytes_disp[rw] = -*bytes;
> +	} else {
> +		tg->bytes_disp[rw] = 0;
> +	}

It should be fine to do	'tg->bytes_disp[rw] = -*bytes;' directly
because `*bytes` is initialized as zero.

> +
> +	if (iops_limit != UINT_MAX) {
>  		*ios = calculate_io_allowed(iops_limit, jiffy_elapsed) -
>  			tg->io_disp[rw];
> -	tg->bytes_disp[rw] -= *bytes;
> -	tg->io_disp[rw] -= *ios;
> +		tg->io_disp[rw] = -*ios;
> +	} else {
> +		tg->io_disp[rw] = 0;
> +	}

Same with above.

Otherwise, this patch looks fine.


thanks,
Ming


  reply	other threads:[~2025-04-17  2:27 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-17  1:50 [PATCH 0/3] blk-throttle: Some bugfixes and modifications Zizhi Wo
2025-04-17  1:50 ` [PATCH 1/3] blk-throttle: Fix wrong tg->[bytes/io]_disp update in __tg_update_carryover() Zizhi Wo
2025-04-17  2:27   ` Ming Lei [this message]
2025-04-17  2:35     ` Zizhi Wo
2025-04-17  2:35     ` Yu Kuai
2025-04-17  1:50 ` [PATCH 2/3] blk-throttle: Delete unnecessary carryover-related fields from throtl_grp Zizhi Wo
2025-04-17  2:34   ` Ming Lei
2025-04-17  2:36   ` Yu Kuai
2025-04-17  1:50 ` [PATCH 3/3] blk-throttle: Add an additional overflow check to the call calculate_bytes/io_allowed Zizhi Wo
2025-04-17  2:39   ` Yu Kuai
2025-04-17  3:27     ` Zizhi Wo

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=aABnBBp4ZZ6pQAOM@fedora \
    --to=ming.lei@redhat.com \
    --cc=axboe@kernel.dk \
    --cc=linux-block@vger.kernel.org \
    --cc=tj@kernel.org \
    --cc=wozizhi@huawei.com \
    --cc=yangerkun@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