From: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
To: linux-block@vger.kernel.org, Jens Axboe <axboe@kernel.dk>,
linux-kernel@vger.kernel.org
Subject: [PATCH 1/2] null_blk: fix handling big requests with small mbps limit
Date: Mon, 08 Jul 2019 18:31:15 +0300 [thread overview]
Message-ID: <156259987576.2590.3397115585587914567.stgit@buzz> (raw)
Small mbps limit actually limits size of request which could be handled,
because 'cur_bytes' never might be bigger than bandwidth limit over 20ms.
For example with mbps=4 device cannot handle requests bigger than 81 KiB.
This patch allows to start request bigger than 'cur_bytes' but stops queue
if 'cur_bytes' is negative. Bandwidth timer takes this into account.
Fixes: eff2c4f10873 ("nullb: bandwidth control")
Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
---
drivers/block/null_blk_main.c | 24 +++++++++++++++++++-----
1 file changed, 19 insertions(+), 5 deletions(-)
diff --git a/drivers/block/null_blk_main.c b/drivers/block/null_blk_main.c
index 447d635c79a2..15925b355965 100644
--- a/drivers/block/null_blk_main.c
+++ b/drivers/block/null_blk_main.c
@@ -1132,6 +1132,18 @@ static void null_restart_queue_async(struct nullb *nullb)
blk_mq_start_stopped_hw_queues(q, true);
}
+static inline bool atomic_long_sub_unless_negative(long i, atomic_long_t *v)
+{
+ long c = atomic_long_read(v);
+
+ do {
+ if (unlikely(c < 0))
+ return false;
+ } while (!atomic_long_try_cmpxchg(v, &c, c - i));
+
+ return true;
+}
+
static blk_status_t null_handle_cmd(struct nullb_cmd *cmd)
{
struct nullb_device *dev = cmd->nq->dev;
@@ -1144,8 +1156,8 @@ static blk_status_t null_handle_cmd(struct nullb_cmd *cmd)
if (!hrtimer_active(&nullb->bw_timer))
hrtimer_restart(&nullb->bw_timer);
- if (atomic_long_sub_return(blk_rq_bytes(rq),
- &nullb->cur_bytes) < 0) {
+ if (!atomic_long_sub_unless_negative(blk_rq_bytes(rq),
+ &nullb->cur_bytes)) {
null_stop_queue(nullb);
/* race with timer */
if (atomic_long_read(&nullb->cur_bytes) > 0)
@@ -1244,12 +1256,14 @@ static enum hrtimer_restart nullb_bwtimer_fn(struct hrtimer *timer)
{
struct nullb *nullb = container_of(timer, struct nullb, bw_timer);
ktime_t timer_interval = ktime_set(0, TIMER_INTERVAL);
- unsigned int mbps = nullb->dev->mbps;
+ long budget = atomic_long_read(&nullb->cur_bytes);
+ long limit = mb_per_tick(nullb->dev->mbps);
- if (atomic_long_read(&nullb->cur_bytes) == mb_per_tick(mbps))
+ if (budget == limit)
return HRTIMER_NORESTART;
- atomic_long_set(&nullb->cur_bytes, mb_per_tick(mbps));
+ atomic_long_set(&nullb->cur_bytes, limit + min(budget, 0L));
+
null_restart_queue_async(nullb);
hrtimer_forward_now(&nullb->bw_timer, timer_interval);
next reply other threads:[~2019-07-08 15:37 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-08 15:31 Konstantin Khlebnikov [this message]
2019-07-08 15:31 ` [PATCH 2/2] null_blk: fix race and oops at removing device with bandwidth limit Konstantin Khlebnikov
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=156259987576.2590.3397115585587914567.stgit@buzz \
--to=khlebnikov@yandex-team.ru \
--cc=axboe@kernel.dk \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.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;
as well as URLs for NNTP newsgroup(s).