From: Christoph Hellwig <hch@lst.de>
To: Naman Jain <namjain@linux.microsoft.com>
Cc: Jens Axboe <axboe@kernel.dk>, Christoph Hellwig <hch@lst.de>,
Chaitanya Kulkarni <kch@nvidia.com>,
John Hubbard <jhubbard@nvidia.com>,
Logan Gunthorpe <logang@deltatee.com>,
linux-kernel@vger.kernel.org, linux-block@vger.kernel.org,
Saurabh Sengar <ssengar@linux.microsoft.com>,
Long Li <longli@microsoft.com>,
Michael Kelley <mhklinux@outlook.com>
Subject: Re: [PATCH 2/2] block: allow different-pgmap pages as separate bvecs in bio_add_page
Date: Wed, 1 Apr 2026 16:08:50 +0200 [thread overview]
Message-ID: <20260401140850.GC21703@lst.de> (raw)
In-Reply-To: <20260401082329.1602328-3-namjain@linux.microsoft.com>
On Wed, Apr 01, 2026 at 08:23:29AM +0000, Naman Jain wrote:
> bio_add_page() and bio_integrity_add_page() reject pages from a
> different dev_pagemap entirely, returning 0 even when the page could
> be added as a new bvec entry. The pgmap check was intended only to
> prevent merging into the same bvec segment, not to block the page
> from being added at all.
>
> This causes callers to unnecessarily start a new bio when a buffer
> spans pages from two different pgmaps, even though the bio has room
> for another bvec.
This is not unnecessary. A single dma mapping operation can only
map a single target pgmap. The old SG API works around this by
doing multiple mapping operation underneath, but compared to that
just having multiple bios is much easier and more efficient.
What is your use case here?
next prev parent reply other threads:[~2026-04-01 14:08 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-01 8:23 [PATCH 0/2] block: fix pgmap handling for zone device pages in bio merge paths Naman Jain
2026-04-01 8:23 ` [PATCH 1/2] block: add pgmap check to biovec_phys_mergeable Naman Jain
2026-04-01 14:07 ` Christoph Hellwig
2026-04-01 8:23 ` [PATCH 2/2] block: allow different-pgmap pages as separate bvecs in bio_add_page Naman Jain
2026-04-01 14:08 ` Christoph Hellwig [this message]
2026-04-02 5:21 ` Naman Jain
2026-04-02 5:30 ` Christoph Hellwig
2026-04-02 8:55 ` Naman Jain
2026-04-07 5:52 ` Christoph Hellwig
2026-04-07 7:08 ` Naman Jain
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=20260401140850.GC21703@lst.de \
--to=hch@lst.de \
--cc=axboe@kernel.dk \
--cc=jhubbard@nvidia.com \
--cc=kch@nvidia.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=logang@deltatee.com \
--cc=longli@microsoft.com \
--cc=mhklinux@outlook.com \
--cc=namjain@linux.microsoft.com \
--cc=ssengar@linux.microsoft.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox