mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Chengming Zhou <zhouchengming@bytedance.com>
To: tj@kernel.org, axboe@kernel.dk
Cc: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
	Chengming Zhou <zhouchengming@bytedance.com>
Subject: [PATCH] blk-iocost: fix lagging in-flight IOs detection
Date: Fri,  3 Jun 2022 17:20:24 +0800	[thread overview]
Message-ID: <20220603092024.49273-1-zhouchengming@bytedance.com> (raw)

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
-- 
2.36.1


             reply	other threads:[~2022-06-03  9:20 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-03  9:20 Chengming Zhou [this message]
2022-06-15 14:53 ` Chengming Zhou

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=20220603092024.49273-1-zhouchengming@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®