From: Ming Lei <ming.lei@redhat.com>
To: Bart Van Assche <bart.vanassche@wdc.com>
Cc: Mike Snitzer <snitzer@redhat.com>,
dm-devel@redhat.com, linux-block@vger.kernel.org
Subject: Re: [PATCH] dm rq: Avoid that request processing stalls sporadically
Date: Fri, 19 Jan 2018 08:11:37 +0800 [thread overview]
Message-ID: <20180119001136.GA4712@ming.t460p> (raw)
In-Reply-To: <20180118163707.11825-1-bart.vanassche@wdc.com>
On Thu, Jan 18, 2018 at 08:37:07AM -0800, Bart Van Assche wrote:
> If the .queue_rq() implementation of a block driver returns
> BLK_STS_RESOURCE then that block driver is responsible for
> rerunning the queue once the condition that caused it to return
> BLK_STS_RESOURCE has been cleared. The dm-mpath driver tells the
> dm core to requeue a request if e.g. not enough memory is
> available for cloning a request or if the underlying path is
> busy. Since the dm-mpath driver does not receive any kind of
> notification if the condition that caused it to return "requeue"
> is cleared, the only solution to avoid that dm-mpath request
> processing stalls is to call blk_mq_delay_run_hw_queue(). Hence
> this patch.
>
> Fixes: ec3eaf9a6731 ("dm mpath: don't call blk_mq_delay_run_hw_queue() in case of BLK_STS_RESOURCE")
> Signed-off-by: Bart Van Assche <bart.vanassche@wdc.com>
> Cc: Ming Lei <ming.lei@redhat.com>
> ---
> drivers/md/dm-rq.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/md/dm-rq.c b/drivers/md/dm-rq.c
> index f16096af879a..c59c59cfd2a5 100644
> --- a/drivers/md/dm-rq.c
> +++ b/drivers/md/dm-rq.c
> @@ -761,6 +761,7 @@ static blk_status_t dm_mq_queue_rq(struct blk_mq_hw_ctx *hctx,
> /* Undo dm_start_request() before requeuing */
> rq_end_stats(md, rq);
> rq_completed(md, rq_data_dir(rq), false);
> + blk_mq_delay_run_hw_queue(hctx, 100/*ms*/);
> return BLK_STS_RESOURCE;
> }
>
Nak.
It still takes a bit time to add this request to hctx->dispatch_list
from here, so suppose the time is longer than 100ms because of interrupt
, preemption or whatever, this request can't be observed in the scheduled
run queue(__blk_mq_run_hw_queue).
Not mention it is just a ugly workaround, which degrades performance
a lot.
--
Ming
next prev parent reply other threads:[~2018-01-19 0:11 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-18 16:37 [PATCH] dm rq: Avoid that request processing stalls sporadically Bart Van Assche
2018-01-18 16:50 ` Mike Snitzer
2018-01-18 17:13 ` Bart Van Assche
2018-01-18 17:13 ` Bart Van Assche
2018-01-19 0:26 ` Ming Lei
2018-01-19 0:26 ` Ming Lei
2018-01-19 0:33 ` Bart Van Assche
2018-01-19 0:33 ` Bart Van Assche
2018-01-19 0:11 ` Ming Lei [this message]
2018-01-19 0:14 ` [PATCH] " Bart Van Assche
2018-01-19 0:14 ` Bart Van Assche
2018-01-19 0:18 ` Ming Lei
2018-01-19 0:18 ` Ming Lei
2018-01-19 0:21 ` Bart Van Assche
2018-01-19 0:21 ` Bart Van Assche
2018-01-19 0:24 ` Jens Axboe
2018-01-19 0:35 ` Ming Lei
2018-01-19 0:49 ` Jens Axboe
2018-01-19 6:36 ` Ming Lei
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=20180119001136.GA4712@ming.t460p \
--to=ming.lei@redhat.com \
--cc=bart.vanassche@wdc.com \
--cc=dm-devel@redhat.com \
--cc=linux-block@vger.kernel.org \
--cc=snitzer@redhat.com \
/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.