linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@kernel.dk>
To: Paolo Valente <paolo.valente@linaro.org>
Cc: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
	ulf.hansson@linaro.org, linus.walleij@linaro.org,
	broonie@kernel.org, bfq-iosched@googlegroups.com,
	oleksandr@natalenko.name, hurikhan77+bko@gmail.com
Subject: Re: [PATCH BUGFIX RFC 0/2] reverting two commits causing freezes
Date: Fri, 18 Jan 2019 06:35:28 -0700	[thread overview]
Message-ID: <c3b182a2-7f82-2860-436b-c1d59d6661ff@kernel.dk> (raw)
In-Reply-To: <20190118115219.63576-1-paolo.valente@linaro.org>

On 1/18/19 4:52 AM, Paolo Valente wrote:
> Hi Jens,
> a user reported a warning, followed by freezes, in case he increases
> nr_requests to more than 64 [1]. After reproducing the issues, I
> reverted the commit f0635b8a416e ("bfq: calculate shallow depths at
> init time"), plus the related commit bd7d4ef6a4c9 ("bfq-iosched:
> remove unused variable"). The problem went away.

For reverts, please put the justification into the actual revert
commit. With this series, if applied as-is, we'd have two patches
in the tree that just says "revert X" without any hint as to why
that was done.

> Maybe the assumption in commit f0635b8a416e ("bfq: calculate shallow
> depths at init time") does not hold true?

It apparently doesn't! But let's try and figure this out instead of
blindly reverting it. OK, I think I see it. For the sched_tags
case, when we grow the requests, we allocate a new set. Hence any
old cache would be stale at that point.

How about something like this? It still keeps the code of having
to update this out of the hot IO path, and only calls it when we
actually change the depths.

Totally untested...


diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
index cd307767a134..b09589915667 100644
--- a/block/bfq-iosched.c
+++ b/block/bfq-iosched.c
@@ -5342,7 +5342,7 @@ static unsigned int bfq_update_depths(struct bfq_data *bfqd,
 	return min_shallow;
 }
 
-static int bfq_init_hctx(struct blk_mq_hw_ctx *hctx, unsigned int index)
+static void bfq_depth_updated(struct blk_mq_hw_ctx *hctx)
 {
 	struct bfq_data *bfqd = hctx->queue->elevator->elevator_data;
 	struct blk_mq_tags *tags = hctx->sched_tags;
@@ -5350,6 +5350,11 @@ static int bfq_init_hctx(struct blk_mq_hw_ctx *hctx, unsigned int index)
 
 	min_shallow = bfq_update_depths(bfqd, &tags->bitmap_tags);
 	sbitmap_queue_min_shallow_depth(&tags->bitmap_tags, min_shallow);
+}
+
+static int bfq_init_hctx(struct blk_mq_hw_ctx *hctx, unsigned int index)
+{
+	bfq_depth_updated(hctx);
 	return 0;
 }
 
@@ -5772,6 +5777,7 @@ static struct elevator_type iosched_bfq_mq = {
 		.requests_merged	= bfq_requests_merged,
 		.request_merged		= bfq_request_merged,
 		.has_work		= bfq_has_work,
+		.depth_updated		= bfq_depth_updated,
 		.init_hctx		= bfq_init_hctx,
 		.init_sched		= bfq_init_queue,
 		.exit_sched		= bfq_exit_queue,
diff --git a/block/blk-mq.c b/block/blk-mq.c
index 3ba37b9e15e9..a047b297ade5 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -3101,6 +3101,8 @@ int blk_mq_update_nr_requests(struct request_queue *q, unsigned int nr)
 		}
 		if (ret)
 			break;
+		if (q->elevator && q->elevator->type->ops.depth_updated)
+			q->elevator->type->ops.depth_updated(hctx);
 	}
 
 	if (!ret)
diff --git a/include/linux/elevator.h b/include/linux/elevator.h
index 2e9e2763bf47..6e8bc53740f0 100644
--- a/include/linux/elevator.h
+++ b/include/linux/elevator.h
@@ -31,6 +31,7 @@ struct elevator_mq_ops {
 	void (*exit_sched)(struct elevator_queue *);
 	int (*init_hctx)(struct blk_mq_hw_ctx *, unsigned int);
 	void (*exit_hctx)(struct blk_mq_hw_ctx *, unsigned int);
+	void (*depth_updated)(struct blk_mq_hw_ctx *);
 
 	bool (*allow_merge)(struct request_queue *, struct request *, struct bio *);
 	bool (*bio_merge)(struct blk_mq_hw_ctx *, struct bio *);

-- 
Jens Axboe


  parent reply	other threads:[~2019-01-18 13:35 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-18 11:52 [PATCH BUGFIX RFC 0/2] reverting two commits causing freezes Paolo Valente
2019-01-18 11:52 ` [PATCH BUGFIX RFC 1/2] Revert "bfq-iosched: remove unused variable" Paolo Valente
2019-01-18 11:52 ` [PATCH BUGFIX RFC 2/2] Revert "bfq: calculate shallow depths at init time" Paolo Valente
2019-01-18 13:35 ` Jens Axboe [this message]
2019-01-18 16:29   ` [PATCH BUGFIX RFC 0/2] reverting two commits causing freezes Jens Axboe
2019-01-18 17:24   ` Paolo Valente
2019-01-18 17:36     ` Jens Axboe

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=c3b182a2-7f82-2860-436b-c1d59d6661ff@kernel.dk \
    --to=axboe@kernel.dk \
    --cc=bfq-iosched@googlegroups.com \
    --cc=broonie@kernel.org \
    --cc=hurikhan77+bko@gmail.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oleksandr@natalenko.name \
    --cc=paolo.valente@linaro.org \
    --cc=ulf.hansson@linaro.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).