linux-block.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Keith Busch <kbusch@kernel.org>
To: Ritesh Harjani <ritesh.list@gmail.com>
Cc: Keith Busch <kbusch@meta.com>,
	linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-ext4@vger.kernel.org,
	snitzer@kernel.org, axboe@kernel.dk, dw@davidwei.uk,
	brauner@kernel.org, hch@lst.de, martin.petersen@oracle.com,
	djwong@kernel.org, linux-xfs@vger.kernel.org,
	viro@zeniv.linux.org.uk, Jan Kara <jack@suse.com>
Subject: Re: [PATCHv3 0/8] direct-io: even more flexible io vectors
Date: Fri, 22 Aug 2025 08:30:14 -0600	[thread overview]
Message-ID: <aKh-9nOqiSbMAtwo@kbusch-mbp> (raw)
In-Reply-To: <87a53ra3mb.fsf@gmail.com>

On Fri, Aug 22, 2025 at 06:57:08PM +0530, Ritesh Harjani wrote:
> Keith Busch <kbusch@meta.com> writes:
> 
> BTW - I did some basic testing of the series against block device, XFS &
> EXT4 and it worked as expected (for both DIO & AIO-DIO) i.e.
> 1. Individial iov_len need not be aligned to the logical block size anymore.
> 2. Total length of iovecs should be logical block size aligned though.
> 
> i.e. this combination works with this patch series now:
> 
>     posix_memalign((void**)&aligned_buf, mem_align, 2 * BLOCK_SIZE);
>     struct iovec iov[4] = {
>         {.iov_base = aligned_buf, .iov_len = 500},
>         {.iov_base = aligned_buf + 500, .iov_len = 1500},
>         {.iov_base = aligned_buf + 2000, .iov_len = 2000},
>         {.iov_base = aligned_buf + 4000, .iov_len = 4192}
>     }; // 500 + 1500 + 2000 + 4192 = 8192

Yep, the kernel would have rejected that before, but should work now. An
added bonus, the code doesn't spend CPU cycles walking the iovec early
anymore.

Your test, though, is not getting to the real good stuff! :) Your
vectors are virtually contiguous, so the block layer will merge them to
maybe only one block sized segment. Add some offsets to create gaps, but
still adhere to your device's dma and virtual boundary limits. Your
offset options may be constrained if you're using NVMe, but I have a
follow up series fixing that for capable hardware.

  reply	other threads:[~2025-08-22 14:30 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-19 16:49 [PATCHv3 0/8] direct-io: even more flexible io vectors Keith Busch
2025-08-19 16:49 ` [PATCHv3 1/8] block: check for valid bio while splitting Keith Busch
2025-08-20  7:02   ` Damien Le Moal
2025-08-20 14:25     ` Keith Busch
2025-08-20  7:04   ` Damien Le Moal
2025-08-25  7:35   ` Christoph Hellwig
2025-08-19 16:49 ` [PATCHv3 2/8] block: add size alignment to bio_iov_iter_get_pages Keith Busch
2025-08-25  7:36   ` Christoph Hellwig
2025-08-19 16:49 ` [PATCHv3 3/8] block: align the bio after building it Keith Busch
2025-08-20  7:07   ` Damien Le Moal
2025-08-25  7:46   ` Christoph Hellwig
2025-08-25 13:57     ` Keith Busch
2025-08-25  7:47   ` Christoph Hellwig
2025-08-26  0:37     ` Keith Busch
2025-08-26  8:02       ` Christoph Hellwig
2025-08-26 23:11         ` Keith Busch
2025-08-19 16:49 ` [PATCHv3 4/8] block: simplify direct io validity check Keith Busch
2025-08-25  7:48   ` Christoph Hellwig
2025-08-19 16:49 ` [PATCHv3 5/8] iomap: " Keith Busch
2025-08-25  7:48   ` Christoph Hellwig
2025-08-19 16:49 ` [PATCHv3 6/8] block: remove bdev_iter_is_aligned Keith Busch
2025-08-25  7:48   ` Christoph Hellwig
2025-08-19 16:49 ` [PATCHv3 7/8] blk-integrity: use simpler alignment check Keith Busch
2025-08-25  7:49   ` Christoph Hellwig
2025-08-19 16:49 ` [PATCHv3 8/8] iov_iter: remove iov_iter_is_aligned Keith Busch
2025-08-25  7:50   ` Christoph Hellwig
2025-08-19 23:36 ` [PATCHv3 0/8] direct-io: even more flexible io vectors Mike Snitzer
2025-08-20  1:52 ` Song Chen
2025-08-22 13:27 ` Ritesh Harjani
2025-08-22 14:30   ` Keith Busch [this message]
2025-08-25 12:07   ` Jan Kara
2025-08-25 14:53     ` Keith Busch
2025-08-26  4:59       ` Ritesh Harjani
2025-08-27 15:20         ` Jan Kara
2025-08-27 16:09           ` Mike Snitzer
2025-09-01  7:55             ` Jan Kara
2025-09-02 14:39               ` Mike Snitzer
2025-08-27 17:52           ` Brian Foster
2025-08-27 19:20           ` Keith Busch
2025-09-01  8:22             ` Jan Kara
2025-08-29  2:11           ` Ritesh Harjani
2025-08-29  3:19             ` Ritesh Harjani

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=aKh-9nOqiSbMAtwo@kbusch-mbp \
    --to=kbusch@kernel.org \
    --cc=axboe@kernel.dk \
    --cc=brauner@kernel.org \
    --cc=djwong@kernel.org \
    --cc=dw@davidwei.uk \
    --cc=hch@lst.de \
    --cc=jack@suse.com \
    --cc=kbusch@meta.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=ritesh.list@gmail.com \
    --cc=snitzer@kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    /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).