From: Chengming Zhou <zhouchengming@bytedance.com>
To: tj@kernel.org, axboe@kernel.dk
Cc: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] blk-iocost: fix lagging in-flight IOs detection
Date: Wed, 15 Jun 2022 22:53:40 +0800 [thread overview]
Message-ID: <e815f04d-2646-05d2-ef96-7cd050ebc31c@bytedance.com> (raw)
In-Reply-To: <20220603092024.49273-1-zhouchengming@bytedance.com>
Hello, friendly ping...
Thanks.
On 2022/6/3 17:20, Chengming Zhou wrote:
> Since latency Qos detection doesn't account for IOs which
> are in-flight for longer than a period, we detect them by
> comparing vdone against period start. If lagging behind
> IOs from past periods, don't increase vrate, but don't let
> cmds which take a very long time pin lagging for too long.
>
> The current code compares vdone against (vnow - period_vtime),
> which is thought to be the period start. But the earliest
> period start should be (vnow - period_vtime - margins.target).
>
> And we will slide forward vtime and vdone on each period timer,
> so we can't depend on vtime to check if the iocg has pinned
> lagging for longer than MAX_LAGGING_PERIODS.
>
> This patch adds lagging_periods in iocg to record how long
> the iocg has pinned lagging, will not be thought as lagging
> if longer than MAX_LAGGING_PERIODS.
>
> Signed-off-by: Chengming Zhou <zhouchengming@bytedance.com>
> ---
> v2:
> - add lagging_periods to check very long lagging iocg.
> ---
> block/blk-iocost.c | 13 +++++++++----
> 1 file changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/block/blk-iocost.c b/block/blk-iocost.c
> index 33a11ba971ea..998bb38ffb37 100644
> --- a/block/blk-iocost.c
> +++ b/block/blk-iocost.c
> @@ -541,6 +541,8 @@ struct ioc_gq {
> u64 indebt_since;
> u64 indelay_since;
>
> + int lagging_periods;
> +
> /* this iocg's depth in the hierarchy and ancestors including self */
> int level;
> struct ioc_gq *ancestors[];
> @@ -2257,10 +2259,13 @@ static void ioc_timer_fn(struct timer_list *timer)
> if ((ppm_rthr != MILLION || ppm_wthr != MILLION) &&
> !atomic_read(&iocg_to_blkg(iocg)->use_delay) &&
> time_after64(vtime, vdone) &&
> - time_after64(vtime, now.vnow -
> - MAX_LAGGING_PERIODS * period_vtime) &&
> - time_before64(vdone, now.vnow - period_vtime))
> - nr_lagging++;
> + time_before64(vdone, ioc->period_at_vtime - ioc->margins.target)) {
> + if (iocg->lagging_periods < MAX_LAGGING_PERIODS) {
> + nr_lagging++;
> + iocg->lagging_periods++;
> + }
> + } else if (iocg->lagging_periods)
> + iocg->lagging_periods = 0;
>
> /*
> * Determine absolute usage factoring in in-flight IOs to avoid
prev parent reply other threads:[~2022-06-15 14:53 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-03 9:20 Chengming Zhou
2022-06-15 14:53 ` Chengming Zhou [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=e815f04d-2646-05d2-ef96-7cd050ebc31c@bytedance.com \
--to=zhouchengming@bytedance.com \
--cc=axboe@kernel.dk \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tj@kernel.org \
/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
all inboxes | Powered by JetHome®