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 false positive lagging
Date: Thu, 26 May 2022 21:35:54 +0800 [thread overview]
Message-ID: <20220526133554.21079-1-zhouchengming@bytedance.com> (raw)
I found many false positive lagging during iocost test.
Since iocg->vtime will be advanced to (vnow - margins.target)
in hweight_after_donation(), which called throw away excess,
the iocg->done_vtime will also be advanced that much.
period_at_vtime <--period_vtime--> vnow
| |
--------------------------------------------------->
|<--->|
margins.target
|->
vtime, done_vtime
If that iocg has some inflight io when vnow, but its done_vtime
is before period_at_vtime, ioc_timer_fn() will think it has
lagging io, even these io maybe issued just before now.
This patch change the condition to check if vdone is before
(period_at_vtime - margins.target) instead of period_at_vtime.
But there is another problem that this patch doesn't fix.
Since vtime will be advanced, we can't check if vtime is
after (vnow - MAX_LAGGING_PERIODS * period_vtime) to tell
whether this iocg pin lagging for too long.
Maybe we can add lagging_periods in iocg to record how many
periods this iocg pin lagging, but I don't know when to clean it.
Signed-off-by: Chengming Zhou <zhouchengming@bytedance.com>
---
block/blk-iocost.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/block/blk-iocost.c b/block/blk-iocost.c
index 33a11ba971ea..42e301b7527b 100644
--- a/block/blk-iocost.c
+++ b/block/blk-iocost.c
@@ -2259,7 +2259,7 @@ static void ioc_timer_fn(struct timer_list *timer)
time_after64(vtime, vdone) &&
time_after64(vtime, now.vnow -
MAX_LAGGING_PERIODS * period_vtime) &&
- time_before64(vdone, now.vnow - period_vtime))
+ time_before64(vdone, ioc->period_at_vtime - ioc->margins.target))
nr_lagging++;
/*
--
2.36.1
next reply other threads:[~2022-05-26 13:36 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-26 13:35 Chengming Zhou [this message]
2022-05-26 17:43 ` [PATCH] blk-iocost: fix false positive lagging Tejun Heo
2022-05-26 23:43 ` [Phishing Risk] [External] " Chengming Zhou
2022-05-28 8:17 ` Chengming Zhou
2022-06-01 12:32 ` 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=20220526133554.21079-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 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.