From: Ming Lei <ming.lei@redhat.com>
To: JeffleXu <jefflexu@linux.alibaba.com>
Cc: Jens Axboe <axboe@kernel.dk>,
linux-block@vger.kernel.org, Christoph Hellwig <hch@lst.de>,
Mike Snitzer <snitzer@redhat.com>,
dm-devel@redhat.com
Subject: Re: [RFC PATCH V2 05/13] block: add req flag of REQ_TAG
Date: Fri, 19 Mar 2021 16:48:35 +0800 [thread overview]
Message-ID: <YFRlYw0efpq/PfMu@T590> (raw)
In-Reply-To: <50e454b9-2027-cf38-0be7-a4ecfdd54027@linux.alibaba.com>
On Fri, Mar 19, 2021 at 03:59:06PM +0800, JeffleXu wrote:
>
>
> On 3/19/21 12:48 AM, Ming Lei wrote:
> > Add one req flag REQ_TAG which will be used in the following patch for
> > supporting bio based IO polling.
> >
> > Exactly this flag can help us to do:
> >
> > 1) request flag is cloned in bio_fast_clone(), so if we mark one FS bio
> > as REQ_TAG, all bios cloned from this FS bio will be marked as REQ_TAG.
> >
> > 2)create per-task io polling context if the bio based queue supports polling
> > and the submitted bio is HIPRI. This per-task io polling context will be
> > created during submit_bio() before marking this HIPRI bio as REQ_TAG. Then
> > we can avoid to create such io polling context if one cloned bio with REQ_TAG
> > is submitted from another kernel context.
> >
> > 3) for supporting bio based io polling, we need to poll IOs from all
> > underlying queues of bio device/driver, this way help us to recognize which
> > IOs need to polled in bio based style, which will be implemented in next
> > patch.
> >
> > Signed-off-by: Ming Lei <ming.lei@redhat.com>
> > ---
> > block/blk-core.c | 29 +++++++++++++++++++++++++++--
> > include/linux/blk_types.h | 4 ++++
> > 2 files changed, 31 insertions(+), 2 deletions(-)
> >
> > diff --git a/block/blk-core.c b/block/blk-core.c
> > index 0b00c21cbefb..efc7a61a84b4 100644
> > --- a/block/blk-core.c
> > +++ b/block/blk-core.c
> > @@ -840,11 +840,30 @@ static inline bool blk_queue_support_bio_poll(struct request_queue *q)
> > static inline void blk_bio_poll_preprocess(struct request_queue *q,
> > struct bio *bio)
> > {
> > + bool mq;
> > +
> > if (!(bio->bi_opf & REQ_HIPRI))
> > return;
> >
> > - if (!blk_queue_poll(q) || (!queue_is_mq(q) && !blk_get_bio_poll_ctx()))
> > + /*
> > + * Can't support bio based IO poll without per-task poll queue
> > + *
> > + * Now we have created per-task io poll context, and mark this
> > + * bio as REQ_TAG, so: 1) if any cloned bio from this bio is
> > + * submitted from another kernel context, we won't create bio
> > + * poll context for it, so that bio will be completed by IRQ;
> > + * 2) If such bio is submitted from current context, we will
> > + * complete it via blk_poll(); 3) If driver knows that one
> > + * underlying bio allocated from driver is for FS bio, meantime
> > + * it is submitted in current context, driver can mark such bio
> > + * as REQ_TAG manually, so the bio can be completed via blk_poll
> > + * too.
> > + */
>
> Sorry I can't understand case 3, could you please further explain it? If
I meant driver may allocate bio and submit it in current context, and this
allocated bio is for completing FS hipri bio too. So far, HIPRI won't be
set for this bio, but driver may mark this bio as HIPRI and TAG, so this
created bio can be polled.
> 'driver marks such bio as REQ_TAG manually', then per-task io poll
> context won't be created, and thus REQ_HIPRI will be cleared, in which
> case the bio will be completed by IRQ. How could it be completed by
> blk_poll()?
The io poll context is created when FS HIPRI bio on based queue(DM) is
submitted, at that time, bio based driver's ->submit_bio isn't called
yet. So when bio driver's ->submit_bio() allocates new bios and submits
them in current context, if driver marks this bio as HIPRI and TAG, they
can be polled too.
>
>
> > + mq = queue_is_mq(q);
> > + if (!blk_queue_poll(q) || (!mq && !blk_get_bio_poll_ctx()))
> > bio->bi_opf &= ~REQ_HIPRI;
>
>
>
>
> If the use cases are mixed, saying one kernel context may submit IO with
> and without REQ_TAG at the meantime (though I don't know if this
> situation exists), then the above code may not work as we expect.
Poll context shouldn't be created for kernel context.
So far, this patch won't cover bios submitted from kernel context, and
for any bios submitted from kernel context, their HIPRI will be cleared.
>
> For example, dm-XXX will return DM_MAPIO_SUBMITTED and actually submits
> the cloned bio (with REQ_TAG) with internal kernel threads. Besides,
> dm-XXX will also allocate bio (without REQ_TAG) of itself for metadata
> logging or something. When submitting bios (without REQ_TAG), per-task
But HIPRI won't be set for this allocated bio.
> io poll context will be allocated. Later when submitting cloned bios
> (with REQ_TAG), the poll context already exists and thus REQ_HIPRI is
> kept for these bios and they are submitted to polling hw queues.
Originally I planed to add new helper of submit_poll_bio() for current
HIPRI uses, and only create poll context in this code path, this way can
decouple REQ_TAG a bit. But looks it is enough to re-use REQ_TAG for this
purpose. If not, it can be quite easy to address issue wrt. creating poll
context.
Thanks,
Ming
next prev parent reply other threads:[~2021-03-19 8:49 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-18 16:48 [RFC PATCH V2 00/13] block: support bio based io polling Ming Lei
2021-03-18 16:48 ` [RFC PATCH V2 01/13] block: add helper of blk_queue_poll Ming Lei
2021-03-19 16:52 ` Mike Snitzer
2021-03-23 11:17 ` Ming Lei
2021-03-18 16:48 ` [RFC PATCH V2 02/13] block: add one helper to free io_context Ming Lei
2021-03-18 16:48 ` [RFC PATCH V2 03/13] block: add helper of blk_create_io_context Ming Lei
2021-03-18 16:48 ` [RFC PATCH V2 04/13] block: create io poll context for submission and poll task Ming Lei
2021-03-19 17:05 ` Mike Snitzer
2021-03-23 11:23 ` Ming Lei
2021-03-18 16:48 ` [RFC PATCH V2 05/13] block: add req flag of REQ_TAG Ming Lei
2021-03-19 7:59 ` JeffleXu
2021-03-19 8:48 ` Ming Lei [this message]
2021-03-19 9:47 ` JeffleXu
2021-03-19 17:38 ` Mike Snitzer
2021-03-23 11:26 ` Ming Lei
2021-03-18 16:48 ` [RFC PATCH V2 06/13] block: add new field into 'struct bvec_iter' Ming Lei
2021-03-19 17:44 ` Mike Snitzer
2021-03-23 11:29 ` Ming Lei
2021-03-18 16:48 ` [RFC PATCH V2 07/13] block/mq: extract one helper function polling hw queue Ming Lei
2021-03-18 16:48 ` [RFC PATCH V2 08/13] block: prepare for supporting bio_list via other link Ming Lei
2021-03-18 16:48 ` [RFC PATCH V2 09/13] block: use per-task poll context to implement bio based io poll Ming Lei
2021-03-18 17:26 ` Mike Snitzer
2021-03-18 17:38 ` [dm-devel] " Mike Snitzer
2021-03-19 0:30 ` Ming Lei
2021-03-19 9:38 ` JeffleXu
2021-03-19 13:46 ` Ming Lei
2021-03-20 5:56 ` JeffleXu
2021-03-23 11:39 ` Ming Lei
2021-03-19 18:38 ` Mike Snitzer
2021-03-23 11:55 ` Ming Lei
2021-03-23 3:46 ` Sagi Grimberg
2021-03-23 12:01 ` Ming Lei
2021-03-23 16:54 ` Sagi Grimberg
2021-03-24 0:10 ` Ming Lei
2021-03-24 15:43 ` Sagi Grimberg
2021-03-18 16:48 ` [RFC PATCH V2 10/13] block: add queue_to_disk() to get gendisk from request_queue Ming Lei
2021-03-18 16:48 ` [RFC PATCH V2 11/13] block: add poll_capable method to support bio-based IO polling Ming Lei
2021-03-18 16:48 ` [RFC PATCH V2 12/13] dm: support IO polling for bio-based dm device Ming Lei
2021-03-18 16:48 ` [RFC PATCH V2 13/13] blk-mq: limit hw queues to be polled in each blk_poll() Ming Lei
2021-03-19 5:50 ` [RFC PATCH V2 00/13] block: support bio based io polling JeffleXu
2021-03-19 18:45 ` Mike Snitzer
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=YFRlYw0efpq/PfMu@T590 \
--to=ming.lei@redhat.com \
--cc=axboe@kernel.dk \
--cc=dm-devel@redhat.com \
--cc=hch@lst.de \
--cc=jefflexu@linux.alibaba.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 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).