From: Ming Lei <ming.lei@redhat.com>
To: Wang Shanker <shankerwangmiao@gmail.com>
Cc: Jens Axboe <axboe@kernel.dk>, Christoph Hellwig <hch@lst.de>,
linux-block@vger.kernel.org
Subject: Re: [PATCH 2/2] block: support bio merge for multi-range discard
Date: Wed, 9 Jun 2021 14:12:32 +0800 [thread overview]
Message-ID: <YMBb0E01P/nXq8fJ@T590> (raw)
In-Reply-To: <AAAB68D1-3F92-4F88-B192-2A202F7CE53D@gmail.com>
On Wed, Jun 09, 2021 at 11:05:59AM +0800, Wang Shanker wrote:
>
>
> > 2021年06月09日 08:45,Ming Lei <ming.lei@redhat.com> 写道:
> >
> > So far multi-range discard treats each bio as one segment(range) of single
> > discard request. This way becomes not efficient if lots of small sized
> > discard bios are submitted, and one example is raid456.
> >
> > Support bio merge for multi-range discard for improving lots of small
> > sized discard bios.
> >
> > Turns out it is easy to support it:
> >
> > 1) always try to merge bio first
> >
> > 2) run into multi-range discard only if bio merge can't be done
> >
> > 3) add rq_for_each_discard_range() for retrieving each range(segment)
> > of discard request
> >
> > Reported-by: Wang Shanker <shankerwangmiao@gmail.com>
> > Signed-off-by: Ming Lei <ming.lei@redhat.com>
> > ---
> > block/blk-merge.c | 12 ++++-----
> > drivers/block/virtio_blk.c | 9 ++++---
> > drivers/nvme/host/core.c | 8 +++---
> > include/linux/blkdev.h | 51 ++++++++++++++++++++++++++++++++++++++
> > 4 files changed, 66 insertions(+), 14 deletions(-)
> >
> > diff --git a/block/blk-merge.c b/block/blk-merge.c
> > index bcdff1879c34..65210e9a8efa 100644
> > --- a/block/blk-merge.c
> > +++ b/block/blk-merge.c
> > @@ -724,10 +724,10 @@ static inline bool blk_discard_mergable(struct request *req)
> > static enum elv_merge blk_try_req_merge(struct request *req,
> > struct request *next)
> > {
> > - if (blk_discard_mergable(req))
> > - return ELEVATOR_DISCARD_MERGE;
> > - else if (blk_rq_pos(req) + blk_rq_sectors(req) == blk_rq_pos(next))
> > + if (blk_rq_pos(req) + blk_rq_sectors(req) == blk_rq_pos(next))
> > return ELEVATOR_BACK_MERGE;
> > + else if (blk_discard_mergable(req))
>
> Shall we adjust how req->nr_phys_segments is calculated in
> bio_attempt_discard_merge() so that multiple contiguous bio's can
> be seen as one segment?
I think it isn't necessary, because we try to merge discard IOs first
just like plain IO. So when bio_attempt_discard_merge() is reached, it
means that IOs can't be merged, so req->nr_phys_segments should be
increased by 1.
Thanks,
Ming
next prev parent reply other threads:[~2021-06-09 6:12 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-09 0:45 [PATCH 0/2] block: discard merge fix & improvement Ming Lei
2021-06-09 0:45 ` [PATCH 1/2] block: fix discard request merge Ming Lei
2021-06-22 6:53 ` Christoph Hellwig
2021-06-22 7:51 ` Ming Lei
2021-06-09 0:45 ` [PATCH 2/2] block: support bio merge for multi-range discard Ming Lei
2021-06-09 3:05 ` Wang Shanker
2021-06-09 6:12 ` Ming Lei [this message]
2021-06-09 6:57 ` Wang Shanker
2021-06-22 6:55 ` Christoph Hellwig
2021-06-22 8:35 ` Miao Wang
2021-06-14 22:00 ` [PATCH 0/2] block: discard merge fix & improvement Ming Lei
2021-06-22 3:53 ` 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=YMBb0E01P/nXq8fJ@T590 \
--to=ming.lei@redhat.com \
--cc=axboe@kernel.dk \
--cc=hch@lst.de \
--cc=linux-block@vger.kernel.org \
--cc=shankerwangmiao@gmail.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.