All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: Bart Van Assche <bvanassche@acm.org>
Cc: Jens Axboe <axboe@kernel.dk>,
	linux-block@vger.kernel.org, Jaegeuk Kim <jaegeuk@kernel.org>,
	Christoph Hellwig <hch@lst.de>, Jan Kara <jack@suse.cz>,
	Ming Lei <ming.lei@redhat.com>,
	Damien Le Moal <damien.lemoal@opensource.wdc.com>,
	Johannes Thumshirn <johannes.thumshirn@wdc.com>
Subject: Re: [PATCH 2/2] block: Split and submit bios in LBA order
Date: Fri, 17 Mar 2023 23:28:13 +0100	[thread overview]
Message-ID: <20230317222813.xkjia2cottjwzls7@quack3> (raw)
In-Reply-To: <20230317195938.1745318-3-bvanassche@acm.org>

On Fri 17-03-23 12:59:38, Bart Van Assche wrote:
> Instead of submitting the bio fragment with the highest LBA first,
> submit the bio fragment with the lowest LBA first. If plugging is
> active, append requests at the end of the list with plugged requests
> instead of at the start. This approach prevents write errors when
> submitting large bios to host-managed zoned block devices.
> 
> Cc: Christoph Hellwig <hch@lst.de>
> Cc: Ming Lei <ming.lei@redhat.com>
> Cc: Damien Le Moal <damien.lemoal@opensource.wdc.com>
> Cc: Johannes Thumshirn <johannes.thumshirn@wdc.com>
> Signed-off-by: Bart Van Assche <bvanassche@acm.org>

...

> diff --git a/block/blk-mq.c b/block/blk-mq.c
> index cc32ad0cd548..9b0f9f3fdba0 100644
> --- a/block/blk-mq.c
> +++ b/block/blk-mq.c
> @@ -1300,7 +1300,7 @@ static inline unsigned short blk_plug_max_rq_count(struct blk_plug *plug)
>  
>  static void blk_add_rq_to_plug(struct blk_plug *plug, struct request *rq)
>  {
> -	struct request *last = rq_list_peek(&plug->mq_list);
> +	struct request *last = rq_list_peek(&plug->mq_list), **last_p;
>  
>  	if (!plug->rq_count) {
>  		trace_block_plug(rq->q);
> @@ -1317,7 +1317,10 @@ static void blk_add_rq_to_plug(struct blk_plug *plug, struct request *rq)
>  	if (!plug->has_elevator && (rq->rq_flags & RQF_ELV))
>  		plug->has_elevator = true;
>  	rq->rq_next = NULL;
> -	rq_list_add(&plug->mq_list, rq);
> +	last_p = &plug->mq_list;
> +	while (*last_p)
> +		last_p = &(*last_p)->rq_next;
> +	rq_list_add_tail(&last_p, rq);
>  	plug->rq_count++;
>  }

Uh, I don't think we want to traverse the whole plug list each time we are
adding a request to it. We have just recently managed to avoid that at
least for single-device cases and apparently it was a win for fast devices
(see commit d38a9c04c0d5 ("block: only check previous entry for plug merge
attempt")).

If anything, I'd rather modify blk_mq_dispatch_plug_list() to add requests
to the queuelist in reverse order in this case, like I did it in
34e0a279a993 ("block: do not reverse request order when flushing plug
list") which is now in Jens' tree.

> diff --git a/include/linux/blk-mq.h b/include/linux/blk-mq.h
> index dd5ce1137f04..5e01791967c0 100644
> --- a/include/linux/blk-mq.h
> +++ b/include/linux/blk-mq.h
> @@ -228,6 +228,12 @@ static inline unsigned short req_get_ioprio(struct request *req)
>  	*(listptr) = rq;				\
>  } while (0)
>  
> +#define rq_list_add_tail(lastpptr, rq) do {		\
> +	(rq)->rq_next = NULL;				\
> +	**(lastpptr) = rq;				\
> +	*(lastpptr) = &rq->rq_next;			\
> +} while (0)
> +

And this function should be already in Jens's tree as part of commit
34e0a279a993 ("block: do not reverse request order when flushing plug
list").

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

  reply	other threads:[~2023-03-17 22:28 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-17 19:59 [PATCH 0/2] Submit split bios in LBA order Bart Van Assche
2023-03-17 19:59 ` [PATCH 1/2] block: Split blk_recalc_rq_segments() Bart Van Assche
2023-03-18  6:38   ` Christoph Hellwig
2023-03-17 19:59 ` [PATCH 2/2] block: Split and submit bios in LBA order Bart Van Assche
2023-03-17 22:28   ` Jan Kara [this message]
2023-03-18  6:33     ` Christoph Hellwig
2023-03-17 23:38   ` Ming Lei
2023-03-17 23:45     ` Bart Van Assche
2023-03-20 23:28       ` Ming Lei
2023-03-20 23:32         ` Bart Van Assche
2023-03-21  0:44           ` Ming Lei
2023-03-21  1:46             ` Damien Le Moal
2023-03-21  2:17               ` Ming Lei
2023-03-21  3:24                 ` Damien Le Moal
2023-03-21  8:00                   ` Ming Lei
2023-03-21  8:51                     ` Damien Le Moal
2023-03-21  9:09                       ` Christoph Hellwig
2023-03-21  9:50                         ` Damien Le Moal
2023-03-21  5:55           ` Christoph Hellwig
2023-03-21 14:36             ` Bart Van Assche
2023-03-23  8:26               ` Christoph Hellwig
2023-03-23 10:28                 ` Damien Le Moal
2023-03-23 16:27                   ` Bart Van Assche
2023-03-23 22:53                     ` Damien Le Moal
2023-03-24 16:55                       ` Bart Van Assche
2023-03-25  2:00                         ` Damien Le Moal
2023-03-25 16:31                           ` Bart Van Assche
2023-03-26  1:45                             ` Damien Le Moal
2023-03-26 23:45                               ` Christoph Hellwig
2023-03-27 21:06                                 ` Bart Van Assche
2023-03-27 23:43                                   ` Christoph Hellwig
2023-04-06 20:30                                     ` Bart Van Assche
2023-03-27 21:20                               ` Bart Van Assche
2023-03-18  6:42   ` Christoph Hellwig
2023-03-18  6:29 ` [PATCH 0/2] Submit split " Christoph Hellwig
2023-03-20 17:22   ` Bart Van Assche
2023-03-20 21:06     ` Khazhy Kumykov
2023-03-23  8:27     ` Christoph Hellwig
2023-03-24 17:05       ` Bart Van Assche
2023-03-25  2:15         ` Damien Le Moal
2023-03-26 23:42           ` Christoph Hellwig
2023-03-26 23:44         ` Christoph Hellwig
2023-04-06 20:32           ` Bart Van Assche

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=20230317222813.xkjia2cottjwzls7@quack3 \
    --to=jack@suse.cz \
    --cc=axboe@kernel.dk \
    --cc=bvanassche@acm.org \
    --cc=damien.lemoal@opensource.wdc.com \
    --cc=hch@lst.de \
    --cc=jaegeuk@kernel.org \
    --cc=johannes.thumshirn@wdc.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 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.