From: Omar Sandoval <osandov@osandov.com>
To: Jens Axboe <axboe@kernel.dk>
Cc: "linux-block@vger.kernel.org" <linux-block@vger.kernel.org>
Subject: Re: [PATCH] null_blk: add 'requeue' fault attribute
Date: Wed, 28 Feb 2018 08:14:08 -0800 [thread overview]
Message-ID: <20180228161408.GA8502@vader> (raw)
In-Reply-To: <1317b3c8-0f6e-a229-414a-de81bb69be2f@kernel.dk>
On Wed, Feb 28, 2018 at 08:28:25AM -0700, Jens Axboe wrote:
> On 2/28/18 1:51 AM, Omar Sandoval wrote:
> > On Tue, Feb 27, 2018 at 03:34:53PM -0700, Jens Axboe wrote:
> >> Similarly to the support we have for testing/faking timeouts for
> >> null_blk, this adds support for triggering a requeue condition.
> >> Considering the issues around restart we've been seeing, this should be
> >> a useful addition to the testing arsenal to ensure that we are handling
> >> requeue conditions correctly.
> >>
> >> This works for queue mode 1 (legacy request_fn based path) and 2 (blk-mq
> >> path), as there's no good way to do requeue with a bio based driver.
> >> This is similar to the timeout path.
> >>
> >> Signed-off-by: Jens Axboe <axboe@kernel.dk>
> >>
> >> ---
> >>
> >> null_blk.c | 55 +++++++++++++++++++++++++++++++++++++++++++------------
> >> 1 file changed, 43 insertions(+), 12 deletions(-)
> >>
> >> diff --git a/drivers/block/null_blk.c b/drivers/block/null_blk.c
> >> index 287a09611c0f..363536572e19 100644
> >> --- a/drivers/block/null_blk.c
> >> +++ b/drivers/block/null_blk.c
> >
> > [snip]
> >
> >> @@ -1422,10 +1440,12 @@ static blk_status_t null_queue_rq(struct blk_mq_hw_ctx *hctx,
> >>
> >> blk_mq_start_request(bd->rq);
> >>
> >> - if (!should_timeout_request(bd->rq))
> >> - return null_handle_cmd(cmd);
> >> + if (should_requeue_request(bd->rq))
> >> + return BLK_STS_RESOURCE;
> >
> > Hm, this goes through the less interesting requeue path, add to the
> > dispatch list and __blk_mq_requeue_request(). blk_mq_requeue_request()
> > is the one that I wanted to test since that's the one that needs to call
> > the scheduler hook.
>
> Until recently, it would have :-)
>
> Both of them are interesting to test, though. Most of the core stall
> cases would have been triggered by going through the STS_RESOURCE case.
> How about we just make it exercise both? The below patch alternates
> between them when we have chosen to requeue.
Works for me. One idle thought, if we set this up to always requeue,
then it won't make any progress. Maybe we should limit the number of
times each request can be requeued so people (me) don't lock up their
test systems? Either way,
Reviewed-by: Omar Sandoval <osandov@fb.com>
next prev parent reply other threads:[~2018-02-28 16:14 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-27 22:34 [PATCH] null_blk: add 'requeue' fault attribute Jens Axboe
2018-02-27 23:35 ` Bart Van Assche
2018-02-28 8:51 ` Omar Sandoval
2018-02-28 15:28 ` Jens Axboe
2018-02-28 16:14 ` Omar Sandoval [this message]
2018-02-28 16:15 ` Jens Axboe
2018-02-28 16:18 ` Omar Sandoval
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=20180228161408.GA8502@vader \
--to=osandov@osandov.com \
--cc=axboe@kernel.dk \
--cc=linux-block@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