From: Christoph Hellwig <hch@lst.de>
To: Ming Lei <ming.lei@redhat.com>
Cc: Christoph Hellwig <hch@lst.de>, Jens Axboe <axboe@kernel.dk>,
linux-block@vger.kernel.org, Guangwu Zhang <guazhang@redhat.com>,
Yu Kuai <yukuai1@huaweicloud.com>
Subject: Re: [PATCH V2 1/2] blk-mq: don't queue plugged passthrough requests into scheduler
Date: Wed, 17 May 2023 09:20:58 +0200 [thread overview]
Message-ID: <20230517072058.GA27026@lst.de> (raw)
In-Reply-To: <ZGM6WYmCNC7vpDIw@ovpn-8-19.pek2.redhat.com>
On Tue, May 16, 2023 at 04:10:01PM +0800, Ming Lei wrote:
> On Tue, May 16, 2023 at 08:22:21AM +0200, Christoph Hellwig wrote:
> > On Mon, May 15, 2023 at 10:46:00PM +0800, Ming Lei wrote:
> > > + } else if (this_hctx != rq->mq_hctx || this_ctx != rq->mq_ctx ||
> > > + pt != blk_rq_is_passthrough(rq)) {
> >
> > Can your format this as:
> >
> > } else if (this_hctx != rq->mq_hctx || this_ctx != rq->mq_ctx ||
> > pt != blk_rq_is_passthrough(rq)) {
> >
> > for readability?
>
> Do you mean indent for 'pt = blk_rq_is_passthrough(rq)' and keep 'pt' aligned
> with 'if' in last line?
Yes.
> > This comment confuses the heck out of me. The check if for passthrough
> > vs non-passthrough and doesn't involved flush requests at all.
> >
> > I'd prefer to drop it, and instead comment on passthrough requests
> > not going to the scheduled below where we actually issue other requests
> > to the scheduler.
>
> Any request can be in plug list in theory, we just don't add flush request
> to plug, that is why the above comment is added. If you don't like the
> words for flush request, I can drop it.
I just don't think it maks any sense in this context. If we want to
enforce the invariant that there's no flush request I'd rather add a
WARN_ON to not only talk about enforce it. I'm not sure it's really
required, though.
> > > + if (pt) {
> > > + spin_lock(&this_hctx->lock);
> > > + list_splice_tail_init(&list, &this_hctx->dispatch);
> > > + spin_unlock(&this_hctx->lock);
> > > + blk_mq_run_hw_queue(this_hctx, from_sched);
> >
> > .. aka here. But why can't we just use the blk_mq_insert_requests
> > for this case anyway?
>
> If the pt request is part of error recovery, it should be issued to
> ->dispatch list directly, so just for the sake of safety, meantime keep
> same behavior with blk_mq_insert_request().
But if it is part of error recovery it won't be plugged. Please don't
do weird cargo cult things here and just use the common helpers.
next prev parent reply other threads:[~2023-05-17 7:21 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-15 14:45 [PATCH V2 0/2] blk-mq: handle passthrough request as really passthrough Ming Lei
2023-05-15 14:46 ` [PATCH V2 1/2] blk-mq: don't queue plugged passthrough requests into scheduler Ming Lei
2023-05-16 6:22 ` Christoph Hellwig
2023-05-16 8:10 ` Ming Lei
2023-05-17 7:20 ` Christoph Hellwig [this message]
2023-05-15 14:46 ` [PATCH V2 2/2] blk-mq: make sure elevator callbacks aren't called for passthrough request Ming Lei
2023-05-15 15:52 ` Bart Van Assche
2023-05-15 20:22 ` Keith Busch
2023-05-16 1:20 ` Ming Lei
2023-05-16 6:24 ` Christoph Hellwig
2023-05-16 8:39 ` Ming Lei
2023-05-17 7:22 ` Christoph Hellwig
2023-05-17 8:58 ` Ming Lei
2023-05-16 14:47 ` Keith Busch
2023-05-17 3:26 ` Ming Lei
2023-05-17 18:13 ` Keith Busch
2023-05-18 1:22 ` 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=20230517072058.GA27026@lst.de \
--to=hch@lst.de \
--cc=axboe@kernel.dk \
--cc=guazhang@redhat.com \
--cc=linux-block@vger.kernel.org \
--cc=ming.lei@redhat.com \
--cc=yukuai1@huaweicloud.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 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).