On Wed, 18 Mar 2026, Keith Busch wrote:
> On Wed, Mar 18, 2026 at 07:16:15PM +0100, Mikulas Patocka wrote:
> > On Wed, 18 Mar 2026, Keith Busch wrote:
> > > On Wed, Mar 18, 2026 at 06:40:52PM +0100, Mikulas Patocka wrote:
> > > > On Wed, 18 Mar 2026, Keith Busch wrote:
> > > >
> > > > > But even then, the only thing I know of that really wants this has an
> > > > > offset that straddles two pages per block, so I never need more than 2
> > > > > segments, and the inline scatterlist has four. There's just currently
> > > > > no
> > > > > way for the block layer to report a max-segments-per-block limit, so
> > > > > I'm
> > > > > including this patch to be consistent with the reportable limits.
> > > >
> > > > Can userspace use preadv/pwritev with many small iovecs on a file
> > > > opened
> > > > for direct I/O?
> > >
> > > Yes, I have several patches that were accepted last year to block and
> > > iomap that align direct-io memory requirements to the backing device's
> > > dma constraints. You can do dword aligned and sized vectored IO to a
> > > block device today if the block limits say its okay.
> >
> > So, we must support worst-case scenario - "cc->sector_size / 4" segments.
> >
> > sector_size can be up to 4096, so there may be up to 1024 segments. Each
> > segment consumes sizeof(struct scatterlist) bytes - that's 32 bytes. So,
> > we allocate up to 32768 bytes.
> >
> > kmalloc with size greater than 32768 is unreliable - so we are just on
> > this limit.
>
> Direct-io hits the BIO_VEC_MAX limit (256) first, so 8k for the
> scatterlist (not great, but less terrible). You can have some 4-byte
> segments in the user request, but the average segement size would have
> to be larger. The important part is that any segment can start at any
> memory address dword alignment offset.
Yes, that makes sense. So, you can preallocate two mempools (for the two
sglists) with 8k-sized objects each.
Mikulas
