From: Mike Snitzer <snitzer@redhat.com>
To: Jens Axboe <axboe@kernel.dk>
Cc: Paolo Valente <paolo.valente@linaro.org>,
Bart Van Assche <Bart.VanAssche@wdc.com>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
dm-devel@redhat.com
Subject: Re: [PATCH v2] block: directly insert blk-mq request from blk_insert_cloned_request()
Date: Mon, 11 Sep 2017 17:13:27 -0400 [thread overview]
Message-ID: <20170911211327.GA17344@redhat.com> (raw)
In-Reply-To: <79287d3a-62e0-912e-dcad-e7ab5297ae34@kernel.dk>
On Mon, Sep 11 2017 at 4:51pm -0400,
Jens Axboe <axboe@kernel.dk> wrote:
> On 09/11/2017 10:16 AM, Mike Snitzer wrote:
> > Here is v2 that should obviate the need to rename blk_mq_insert_request
> > (by using bools to control run_queue and async).
> >
> > As for inserting directly into dispatch, if that can be done that is
> > great but I'd prefer to have that be a follow-up optimization. This
> > fixes the regression in question, and does so in well-known terms.
> >
> > What do you think?
>
> I think it looks reasonable. My only concern is the use of the software
> queues. Depending on the scheduler, they may or may not be used. I'd
> need to review the code, but my first thought is that this would break
> if you use blk_mq_insert_request() on a device that is managed by
> mq-deadline or bfq, for instance. Schedulers are free to use the
> software queues, but they are also free to ignore them and use internal
> queuing.
>
> Looking at the code, looks like this was changed slightly at some point,
> we always flush the software queues, if any of them contain requests. So
> it's probably fine.
OK good, but is that too brittle to rely on? Something that might change
in the future?
> My earlier suggestion to use just hctx->dispatch for the IO and bypass
> the software queues completely. The use case for the dispatch list is
> the same, regardless of whether the device has a scheduler attached or
> not.
I'm missing how these details relate to the goal of bypassing any
scheduler that might be attached. Are you saying the attached elevator
would still get in the way?
Looking at blk_mq_sched_insert_request(), submission when an elevator
isn't attached is exactly what I made blk_mq_insert_request() do (which
is exactly what it did in the past).
In the case of DM multipath, nothing else should be submitting IO to the
device so elevator shouldn't be used -- only interface for submitting IO
would be blk_mq_insert_request(). So even if a scheduler is attached it
should be bypassed right?
Mike
next prev parent reply other threads:[~2017-09-11 21:13 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-24 23:16 BFQ + dm-mpath Bart Van Assche
2017-08-30 16:31 ` Paolo Valente
2017-09-05 7:56 ` Paolo Valente
2017-09-05 14:15 ` Bart Van Assche
2017-09-07 15:52 ` Mike Snitzer
2017-09-08 9:13 ` Paolo Valente
2017-09-08 9:13 ` Paolo Valente
2017-09-08 16:41 ` [PATCH] dm mpath: switch IO scheduler of underlying paths to "none" [was: Re: BFQ + dm-mpath] Mike Snitzer
2017-09-08 16:48 ` Jens Axboe
2017-09-08 17:07 ` Mike Snitzer
2017-09-08 19:58 ` Mike Snitzer
2017-09-08 20:28 ` Jens Axboe
2017-09-08 21:42 ` [PATCH] block: directly insert blk-mq request from blk_insert_cloned_request() Mike Snitzer
2017-09-08 21:50 ` Jens Axboe
2017-09-08 22:03 ` Mike Snitzer
2017-09-11 16:16 ` [PATCH v2] " Mike Snitzer
2017-09-11 20:51 ` Jens Axboe
2017-09-11 21:13 ` Mike Snitzer [this message]
2017-09-11 21:27 ` Jens Axboe
2017-09-11 21:51 ` Mike Snitzer
2017-09-11 22:30 ` Mike Snitzer
2017-09-11 22:43 ` Jens Axboe
2017-09-14 15:57 ` Ming Lei
2017-09-14 16:30 ` Jens Axboe
2017-09-14 16:33 ` Ming Lei
2017-09-14 16:34 ` 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=20170911211327.GA17344@redhat.com \
--to=snitzer@redhat.com \
--cc=Bart.VanAssche@wdc.com \
--cc=axboe@kernel.dk \
--cc=dm-devel@redhat.com \
--cc=linux-block@vger.kernel.org \
--cc=paolo.valente@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 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.