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.
