From: Jens Axboe <axboe@kernel.dk>
To: Dennis Zhou <dennis@kernel.org>, Josef Bacik <josef@toxicpanda.com>
Cc: kernel-team@fb.com, linux-block@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] blk-iolatency: fix STS_AGAIN handling
Date: Fri, 5 Jul 2019 14:46:05 -0600 [thread overview]
Message-ID: <4558ef3a-bc60-aa56-8aa4-4427206e2864@kernel.dk> (raw)
In-Reply-To: <20190705203228.77695-1-dennis@kernel.org>
On 7/5/19 2:32 PM, Dennis Zhou wrote:
> The iolatency controller is based on rq_qos. It increments on
> rq_qos_throttle() and decrements on either rq_qos_cleanup() or
> rq_qos_done_bio(). a3fb01ba5af0 fixes the double accounting issue where
> blk_mq_make_request() may call both rq_qos_cleanup() and
> rq_qos_done_bio() on REQ_NO_WAIT. So checking STS_AGAIN prevents the
> double decrement.
>
> The above works upstream as the only way we can get STS_AGAIN is from
> blk_mq_get_request() failing. The STS_AGAIN handling isn't a real
> problem as bio_endio() skipping only happens on reserved tag allocation
> failures which can only be caused by driver bugs and already triggers
> WARN.
>
> However, the fix creates a not so great dependency on how STS_AGAIN can
> be propagated. Internally, we (Facebook) carry a patch that kills read
> ahead if a cgroup is io congested or a fatal signal is pending. This
> combined with chained bios progagate their bi_status to the parent is
> not already set can can cause the parent bio to not clean up properly
> even though it was successful. This consequently leaks the inflight
> counter and can hang all IOs under that blkg.
>
> To nip the adverse interaction early, this removes the rq_qos_cleanup()
> callback in iolatency in favor of cleaning up always on the
> rq_qos_done_bio() path.
>
> Fixes: a3fb01ba5af0 ("blk-iolatency: only account submitted bios")
> Debugged-by: Tejun Heo <tj@kernel.org>
> Debugged-by: Josef Bacik <josef@toxicpanda.com>
> Signed-off-by: Dennis Zhou <dennis@kernel.org>
> ---
> block/blk-iolatency.c | 29 +++--------------------------
> 1 file changed, 3 insertions(+), 26 deletions(-)
>
> diff --git a/block/blk-iolatency.c b/block/blk-iolatency.c
> index e8859350ab6e..c956eebf2d97 100644
> --- a/block/blk-iolatency.c
> +++ b/block/blk-iolatency.c
> @@ -600,10 +600,6 @@ static void blkcg_iolatency_done_bio(struct rq_qos *rqos, struct bio *bio)
> if (!blkg || !bio_flagged(bio, BIO_TRACKED))
> return;
>
> - /* We didn't actually submit this bio, don't account it. */
> - if (bio->bi_status == BLK_STS_AGAIN)
> - return;
> -
> iolat = blkg_to_lat(bio->bi_blkg);
> if (!iolat)
> return;
> @@ -622,6 +618,9 @@ static void blkcg_iolatency_done_bio(struct rq_qos *rqos, struct bio *bio)
>
> inflight = atomic_dec_return(&rqw->inflight);
> WARN_ON_ONCE(inflight < 0);
> + /* We didn't actually submit this bio, don't account for it. */
> + if (bio->bi_status == BLK_STS_AGAIN)
> + goto next;
> if (iolat->min_lat_nsec == 0)
> goto next;
> iolatency_record_time(iolat, &bio->bi_issue, now,
Patch in general looks fine to me, but let's get rid of this next label,
it's pretty silly. Only one use of it, why not just make it a nested if?
--
Jens Axboe
prev parent reply other threads:[~2019-07-05 20:46 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-05 20:32 [PATCH] blk-iolatency: fix STS_AGAIN handling Dennis Zhou
2019-07-05 20:46 ` Jens Axboe [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=4558ef3a-bc60-aa56-8aa4-4427206e2864@kernel.dk \
--to=axboe@kernel.dk \
--cc=dennis@kernel.org \
--cc=josef@toxicpanda.com \
--cc=kernel-team@fb.com \
--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