From: Christoph Hellwig <hch@infradead.org>
To: Keith Busch <kbusch@meta.com>
Cc: linux-block@vger.kernel.org, linux-nvme@lists.infradead.org,
hch@lst.de, axboe@kernel.dk, Keith Busch <kbusch@kernel.org>
Subject: Re: [PATCHv3 1/2] block: accumulate segment page gaps per bio
Date: Mon, 25 Aug 2025 06:46:50 -0700 [thread overview]
Message-ID: <aKxpSorluMXgOFEI@infradead.org> (raw)
In-Reply-To: <20250821204420.2267923-2-kbusch@meta.com>
On Thu, Aug 21, 2025 at 01:44:19PM -0700, Keith Busch wrote:
> +static inline unsigned int bvec_seg_gap(struct bio_vec *bv, struct bio_vec *bvprv)
Nit: overly long line.
> +{
> + return ((bvprv->bv_offset + bvprv->bv_len) & (PAGE_SIZE - 1)) |
> + bv->bv_offset;
But what's actually more important is a good name, and a good comment.
Without much of an explanation this just looks like black magic :)
Also use the chance to document why all this is PAGE_SIZE based and
not based on either the iommu granule size or the virt boundary.
> + if (bvprvp) {
> + if (bvec_gap_to_prev(lim, bvprvp, bv.bv_offset))
> + goto split;
> + page_gaps |= bvec_seg_gap(&bv, &bvprv);
> + }
>
> if (nsegs < lim->max_segments &&
> bytes + bv.bv_len <= max_bytes &&
> @@ -326,6 +335,7 @@ int bio_split_io_at(struct bio *bio, const struct queue_limits *lim,
> }
>
> *segs = nsegs;
> + bio->bi_pg_bit = ffs(page_gaps);
Caling this "bit" feels odd. I guess the idea is that you only care
about power of two alignments? I think this would be much easier
with the whole theory of operation spelled out somewhere in detail,
including why the compression to the set bits works, why the PAGE
granularity matters, why we only need to set this bit when splitting
but not on bios that never gets split or at least looped over for
splitting decisions.
> enum rw_hint bi_write_hint;
> u8 bi_write_stream;
> blk_status_t bi_status;
> +
> + /*
> + * The page gap bit indicates the lowest set bit in any page address
> + * offset between all bi_io_vecs. This field is initialized only after
> + * splitting to the hardware limits.
> + */
> + u8 bi_pg_bit;
Maybe move this one up so that all the field only set on the submission
side stay together?
next prev parent reply other threads:[~2025-08-25 15:03 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-21 20:44 [PATCHv3 0/2] block+nvme: reducing virtual boundary mask reliance Keith Busch
2025-08-21 20:44 ` [PATCHv3 1/2] block: accumulate segment page gaps per bio Keith Busch
2025-08-25 13:46 ` Christoph Hellwig [this message]
2025-08-25 14:10 ` Keith Busch
2025-08-26 13:03 ` Christoph Hellwig
2025-08-26 13:47 ` Keith Busch
2025-08-26 13:57 ` Christoph Hellwig
2025-08-26 22:33 ` Keith Busch
2025-08-27 7:37 ` Christoph Hellwig
2025-08-30 1:47 ` Keith Busch
2025-09-02 5:36 ` Christoph Hellwig
2025-08-21 20:44 ` [PATCHv3 2/2] nvme: remove virtual boundary for sgl capable devices Keith Busch
2025-08-25 13:49 ` Christoph Hellwig
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=aKxpSorluMXgOFEI@infradead.org \
--to=hch@infradead.org \
--cc=axboe@kernel.dk \
--cc=hch@lst.de \
--cc=kbusch@kernel.org \
--cc=kbusch@meta.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
/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).