Re: [PATCH v1 03/11] io_uring/kbuf: add support for kernel-managed buffer rings

[Pavel Begunkov <asml.silence@gmail.com>]

On 2/27/26 01:12, Joanne Koong wrote:
...
>>> Regions shouldn't know anything about your buffers, how it's
>>> subdivided after, etc.
> 
> I still think the memory for the buffers should be tied to the ring
> itself and allocated physically contiguously per buffer. Per-buffer
> contiguity will enable the most efficient DMA path for servers to send
> read/write data to local storage or the network. If the buffers for
> the bufring have to be allocated as one single memory region, the
> io_mem_alloc_compound() call will fail for this large allocation size.
> Even if io_mem_alloc_compound() did succeed, this is a waste as the
> buffer pool as an entity doesn't need to be physically contiguous,
> just the individual buffers themselves. For fuse, the server
> configures what buffer pool size it wants to use, depending on what
> queue depth and max request size it needs. So for most use cases, at
> least for high-performance servers, allocation will have to fall back
> to alloc_pages_bulk_node(), which doesn't allocate contiguously. You
> mentioned in an earlier comment that this "only violates abstractions"
> - which abstractions does this break? The pre-existing behavior
> already defaults to allocating pages non-contiguously if the mem
> region can't be allocated fully contiguously.

Regions has uapi (see struct io_uring_region_desc) so that users
can operate with them in a unified manner. If you want regions to
be allocated in some special way, just extend it.

> Going through registered buffers doesn't help either. Fuse servers can
> be unprivileged and it's not guaranteed that there are enough huge
> pages reserved or that another process hasn't taken them or that the
> server has privileges to pre-reserve pages for the allocation. Also

There is THP these days. And FWIW, we should be vigilant about not
using io_uring to work around capabilities and mm policies. If user
can't do it, io_uring shouldn't either. It's also all accounted
against mlock, if the limit is not high enough, you won't be able
to use this feature at all.

> the 2 MB granularity is inflexible while 1 GB is too much.

-- 
Pavel Begunkov