linux-block.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mike Snitzer <snitzer@redhat.com>
To: Ming Lei <ming.lei@redhat.com>
Cc: Jens Axboe <axboe@kernel.dk>,
	linux-block@vger.kernel.org, Christoph Hellwig <hch@lst.de>,
	Jeffle Xu <jefflexu@linux.alibaba.com>,
	dm-devel@redhat.com
Subject: Re: [RFC PATCH V2 05/13] block: add req flag of REQ_TAG
Date: Fri, 19 Mar 2021 13:38:13 -0400	[thread overview]
Message-ID: <20210319173813.GC9938@redhat.com> (raw)
In-Reply-To: <20210318164827.1481133-6-ming.lei@redhat.com>

On Thu, Mar 18 2021 at 12:48pm -0400,
Ming Lei <ming.lei@redhat.com> wrote:

> Add one req flag REQ_TAG which will be used in the following patch for
> supporting bio based IO polling.

"REQ_TAG" is so generic yet is used in such a specific way (to mark an
FS bio as having polling context)

I don't have a great suggestion for a better name, just seems "REQ_TAG"
is lacking... (especially given the potential for confusion due to
blk-mq's notion of "tag").

REQ_FS? REQ_FS_CTX? REQ_POLL? REQ_POLL_CTX? REQ_NAMING_IS_HARD :)

Maybe others have better ideas?

Mike

> 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.
> +	 */
> +	mq = queue_is_mq(q);
> +	if (!blk_queue_poll(q) || (!mq && !blk_get_bio_poll_ctx()))
>  		bio->bi_opf &= ~REQ_HIPRI;
> +	else if (!mq)
> +		bio->bi_opf |= REQ_TAG;
>  }
>  
>  static noinline_for_stack bool submit_bio_checks(struct bio *bio)
> @@ -893,9 +912,15 @@ static noinline_for_stack bool submit_bio_checks(struct bio *bio)
>  
>  	/*
>  	 * Created per-task io poll queue if we supports bio polling
> -	 * and it is one HIPRI bio.
> +	 * and it is one HIPRI bio, and this HIPRI bio has to be from
> +	 * FS. If REQ_TAG isn't set for HIPRI bio, we think it originated
> +	 * from FS.
> +	 *
> +	 * Driver may allocated bio by itself and REQ_TAG is set, but they
> +	 * won't be marked as HIPRI.
>  	 */
>  	blk_create_io_context(q, blk_queue_support_bio_poll(q) &&
> +			!(bio->bi_opf & REQ_TAG) &&
>  			(bio->bi_opf & REQ_HIPRI));
>  
>  	blk_bio_poll_preprocess(q, bio);
> diff --git a/include/linux/blk_types.h b/include/linux/blk_types.h
> index db026b6ec15a..a1bcade4bcc3 100644
> --- a/include/linux/blk_types.h
> +++ b/include/linux/blk_types.h
> @@ -394,6 +394,9 @@ enum req_flag_bits {
>  
>  	__REQ_HIPRI,
>  
> +	/* for marking IOs originated from same FS bio in same context */
> +	__REQ_TAG,
> +
>  	/* for driver use */
>  	__REQ_DRV,
>  	__REQ_SWAP,		/* swapping request. */
> @@ -418,6 +421,7 @@ enum req_flag_bits {
>  
>  #define REQ_NOUNMAP		(1ULL << __REQ_NOUNMAP)
>  #define REQ_HIPRI		(1ULL << __REQ_HIPRI)
> +#define REQ_TAG			(1ULL << __REQ_TAG)
>  
>  #define REQ_DRV			(1ULL << __REQ_DRV)
>  #define REQ_SWAP		(1ULL << __REQ_SWAP)
> -- 
> 2.29.2
> 


  parent reply	other threads:[~2021-03-19 17:39 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
2021-03-19  9:47       ` JeffleXu
2021-03-19 17:38   ` Mike Snitzer [this message]
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=20210319173813.GC9938@redhat.com \
    --to=snitzer@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=ming.lei@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).