Linux-NVME Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Keith Busch <kbusch@kernel.org>
To: Christoph Hellwig <hch@lst.de>
Cc: Keith Busch <kbusch@meta.com>,
	linux-block@vger.kernel.org, linux-nvme@lists.infradead.org,
	axboe@kernel.dk
Subject: Re: [PATCH 1/2] block: accumulate segment page gaps per bio
Date: Mon, 11 Aug 2025 09:27:18 -0600	[thread overview]
Message-ID: <aJoL1rsvI5bXkod_@kbusch-mbp> (raw)
In-Reply-To: <20250810143112.GA4860@lst.de>

On Sun, Aug 10, 2025 at 04:31:12PM +0200, Christoph Hellwig wrote:
> On Wed, Aug 06, 2025 at 09:44:47AM -0600, Keith Busch wrote:
> > 
> > Maybe, but I don't have anywhere else to put this. We split the bio to
> > its hardware limits at some point, which is where this field gets
> > initially set.
> 
> What we do for nr_segs is to just do it on stack while splitting,
> and then only record it in the request.  I think you could do the same
> here, i.e. replace the nr_segs output parameter to __bio_split_to_limits
> and it's helpers with a new struct bio_split_info that in the first
> version just contains nr_segs, but can be extended to other easily
> derived information like the page gaps.

I initially tried to copy the nsegs usage in the request, but there are
multiple places (iomap, xfs, and btrfs) that split to hardware limits
without a request, so I'm not sure where the result is supposed to go to
be referenced later. Or do those all call the same split function later
in the generic block layer, in which case it shouldn't matter if the
upper layers already called it?


  reply	other threads:[~2025-08-11 22:01 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-05 19:56 [PATCH 1/2] block: accumulate segment page gaps per bio Keith Busch
2025-08-05 19:56 ` [PATCH 2/2] nvme: remove virtual boundary for sgl capable devices Keith Busch
2025-08-06 14:55   ` Christoph Hellwig
2025-08-06 15:04     ` Keith Busch
2025-08-05 20:32 ` [PATCH 1/2] block: accumulate segment page gaps per bio Caleb Sander Mateos
2025-08-05 20:52   ` Keith Busch
2025-08-05 22:52 ` Keith Busch
2025-08-06 14:53   ` Christoph Hellwig
2025-08-06 15:17     ` Keith Busch
2025-08-06 14:56 ` Christoph Hellwig
2025-08-06 15:44   ` Keith Busch
2025-08-10 14:31     ` Christoph Hellwig
2025-08-11 15:27       ` Keith Busch [this message]
2025-08-11 16:17         ` Christoph Hellwig
2025-08-20 19:22           ` Keith Busch

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=aJoL1rsvI5bXkod_@kbusch-mbp \
    --to=kbusch@kernel.org \
    --cc=axboe@kernel.dk \
    --cc=hch@lst.de \
    --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