From: Christoph Hellwig <hch@lst.de>
To: Keith Busch <kbusch@meta.com>
Cc: axboe@kernel.dk, hch@lst.de, martin.petersen@oracle.com,
linux-block@vger.kernel.org, linux-nvme@lists.infradead.org,
linux-scsi@vger.kernel.org, sagi@grimberg.me,
Keith Busch <kbusch@kernel.org>
Subject: Re: [PATCHv4 04/10] blk-integrity: consider entire bio list for merging
Date: Thu, 12 Sep 2024 09:42:05 +0200 [thread overview]
Message-ID: <20240912074205.GA8202@lst.de> (raw)
In-Reply-To: <20240911201240.3982856-5-kbusch@meta.com>
On Wed, Sep 11, 2024 at 01:12:34PM -0700, Keith Busch wrote:
> From: Keith Busch <kbusch@kernel.org>
>
> If a bio is merged to a request, the entire bio list is merged, so don't
> temporarily detach it from its list when counting segments. In most
> cases, bi_next will already be NULL, so detaching is usually a no-op.
> But if the bio does have a list, the current code is miscounting the
> segments for the resulting merge.
As far as I can tell we can never get here with bi_next set. Rationale:
blk_integrity_merge_bio has two callers: ll_new_hw_segment and
blk_rq_merge_ok.
ll_new_hw_segment is called from ll_back_merge_fn and ll_front_merge_fn.
ll_back_merge_fn is called from blk_rq_append_bio and
bio_attempt_back_merge.
blk_rq_append_bio is always used for a single bio and in fact used
to build bio chains.
bio_attempt_back_merge is called from blk_attempt_bio_merge,
blk_mq_sched_try_merge and blk_zone_write_plug_init_request.
blk_attempt_bio_merge is called from blk_attempt_plug_merge and
blk_bio_list_merge.
blk_attempt_plug_merge is called from blk_mq_attempt_bio_merge,
which always operates on a single bio.
blk_bio_list_merge is called from blk_mq_sched_bio_merge,
kyber_bio_merge where the latter is just an indirect call from
the former, and blk_mq_sched_bio_merge is called from
blk_mq_attempt_bio_merge which was considered above.
blk_mq_sched_try_merge is called from bfq_bio_merge and dd_bio_merge,
both of which are implementation of the ->bio_merge elevator_mq_ops
method called from blk_mq_sched_bio_merge, which was considered above.
blk_zone_write_plug_init_request is called from blk_mq_submit_bio
and always operates on a single bio.
ll_front_merge_fn is called from bio_attempt_front_merge.
bio_attempt_front_merge is called from blk_attempt_bio_merge and
blk_mq_sched_try_merge, both of which were considered above.
blk_rq_merge_ok is called from blk_attempt_bio_merge,
blk_zone_write_plug_init_request and elv_bio_merge_ok.
blk_attempt_bio_merge and blk_zone_write_plug_init_request were
already considered above.
elv_bio_merge_ok is called from bfq_request_merge and dd_request_merge
and elv_merge. The first two are implementations of the ->request_merge
elevator_mq_ops method called from elv_merge, which is called from
blk_mq_sched_try_merge, which was considered above.
Also it feels like the call in blk_rq_merge_ok is superflous from this.
next prev parent reply other threads:[~2024-09-12 7:42 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-11 20:12 [PATCHv4 00/10] block integrity merging and counting Keith Busch
2024-09-11 20:12 ` [PATCHv4 01/10] blk-mq: unconditional nr_integrity_segments Keith Busch
2024-09-12 7:02 ` Christoph Hellwig
2024-09-13 1:47 ` Martin K. Petersen
2024-09-11 20:12 ` [PATCHv4 02/10] blk-mq: set the nr_integrity_segments from bio Keith Busch
2024-09-13 1:47 ` Martin K. Petersen
2024-09-11 20:12 ` [PATCHv4 03/10] blk-integrity: properly account for segments Keith Busch
2024-09-13 1:48 ` Martin K. Petersen
2024-09-11 20:12 ` [PATCHv4 04/10] blk-integrity: consider entire bio list for merging Keith Busch
2024-09-12 7:42 ` Christoph Hellwig [this message]
2024-09-11 20:12 ` [PATCHv4 05/10] block: provide a request helper for user integrity segments Keith Busch
2024-09-12 7:43 ` Christoph Hellwig
2024-09-13 1:50 ` Martin K. Petersen
2024-09-13 12:33 ` Kanchan Joshi
2024-09-11 20:12 ` [PATCHv4 06/10] block: provide helper for nr_integrity_segments Keith Busch
2024-09-12 7:44 ` Christoph Hellwig
2024-09-13 1:52 ` Martin K. Petersen
2024-09-13 12:35 ` Kanchan Joshi
2024-09-11 20:12 ` [PATCHv4 07/10] scsi: use request helper to get integrity segments Keith Busch
2024-09-13 1:53 ` Martin K. Petersen
2024-09-13 12:35 ` Kanchan Joshi
2024-09-11 20:12 ` [PATCHv4 08/10] nvme-rdma: " Keith Busch
2024-09-13 1:54 ` Martin K. Petersen
2024-09-13 12:37 ` Kanchan Joshi
2024-09-11 20:12 ` [PATCHv4 09/10] block: unexport blk_rq_count_integrity_sg Keith Busch
2024-09-13 1:54 ` Martin K. Petersen
2024-09-11 20:12 ` [PATCHv4 10/10] blk-integrity: improved sg segment mapping Keith Busch
2024-09-11 23:23 ` Keith Busch
2024-09-12 7:46 ` Christoph Hellwig
2024-09-12 7:47 ` Christoph Hellwig
2024-09-13 2:00 ` Martin K. Petersen
2024-09-13 3:45 ` kernel test robot
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=20240912074205.GA8202@lst.de \
--to=hch@lst.de \
--cc=axboe@kernel.dk \
--cc=kbusch@kernel.org \
--cc=kbusch@meta.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=sagi@grimberg.me \
/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.