From: Keith Busch <kbusch@kernel.org>
To: Mikulas Patocka <mpatocka@redhat.com>
Cc: Keith Busch <kbusch@meta.com>,
dm-devel@lists.linux.dev, snitzer@kernel.org,
linux-block@vger.kernel.org, ebiggers@google.com
Subject: Re: [RFC PATCH] dm-crypt: allow unaligned bio_vecs for direct io
Date: Fri, 26 Sep 2025 10:17:07 -0600 [thread overview]
Message-ID: <aNa8g0IZuQZvA93v@kbusch-mbp> (raw)
In-Reply-To: <f3d06d99-638d-99a5-03e3-686b544d97ac@redhat.com>
On Fri, Sep 26, 2025 at 04:19:58PM +0200, Mikulas Patocka wrote:
>
> I'd like to ask - how much does it help performance? How many percent
> faster does your application run?
The best info I have from the storage team I'm working with is this
reduces their application's memory bandwidth utilization by a little
over 10%.
> Another question - what if the user uses preadv or pwritev with direct I/O
> and uses more than 4 sg lists? Will this be rejected in the upper layers,
> or will it reach dm-crypt and return -EINVAL?
I believe it would reach dm-crypt with this patch.
If you tried today, it should get rejected by the upper layers for
unalignement. But there are some changes pending in the 6.18 block tree
that defer the alignment detection to later such that dm-crypt may have
to deal with this and fail the IO (unless something higher splits the
bio to its queue limits first), so sounds like I should sort that out.
Regarding the 4 scatterlist limit, we're using 4k sized logical blocks.
The incoming data typically has an offset crossing a page boundary, so
needs 2 pages for each block. Just 2 scatterlists would do the trick.
If we really want to remove all software constraints here, then we could
increase the pre-allocated scatterlist size, or dynamically allocate an
approrpiate scatter gather table per-io. I guess we'd have to expand the
list somewhere if this needs to work with aead, too.
> Note that returning error
> from dm-crypt may be quite problematic, because it would kick the leg out
> of RAID, if there were RAID above dm-crypt. I think that we should return
> BLK_STS_NOTSUPP, because that would be ignored by RAID.
Thanks, I'll try this out.
> I am considering committing this for the kernel 6.19 (it's too late to add
> it to the 6.18 merge window).
No problem, I don't want to rush this. Your reply is at least
encouraging enough for me to sort out more than just "plaint64" with
this proposal.
next prev parent reply other threads:[~2025-09-26 16:17 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-18 16:16 [RFC PATCH] dm-crypt: allow unaligned bio_vecs for direct io Keith Busch
2025-09-18 20:13 ` Keith Busch
2025-09-26 14:19 ` Mikulas Patocka
2025-09-26 16:17 ` Keith Busch [this message]
2025-09-18 20:27 ` Mike Snitzer
2025-09-18 20:52 ` 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=aNa8g0IZuQZvA93v@kbusch-mbp \
--to=kbusch@kernel.org \
--cc=dm-devel@lists.linux.dev \
--cc=ebiggers@google.com \
--cc=kbusch@meta.com \
--cc=linux-block@vger.kernel.org \
--cc=mpatocka@redhat.com \
--cc=snitzer@kernel.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