Re: [RFC v1] io_uring/rsrc: add fast path huge page handling in buffer registration

[David Hildenbrand (Arm)]

On 6/10/26 13:34, Christoph Hellwig wrote:
> On Wed, Jun 10, 2026 at 11:54:01AM +0200, David Hildenbrand (Arm) wrote:
>>> Yes.  iov_iter_extract_bvecs and thus the block direct I/O fast path
>>> would instantly benefit from that.
>> The tricky bit for such an interface is that, soon, some pages won't be folios,
>> but we could still end up with non-folio pages in the address space (e.g.,
>> vm_insert_page()) and have to pin+return them. So using folios is not future-proof.
> 
> I'm still doubtful on the "soon" beause of all the issues like this
> in the I/O path.

Yeah, there are a bunch of very hairy things.

> 
>> There are some long-term plans on providing an interface that would abstract how
>> you refcount something you GUP'ed. (because, some pages we GUP in the future
>> might not even have a dedicated refcount, all still fairly unclear). But it's
>> all not really finalized I think.
>>
>> For now, we could expose a folio+page/offset+nr_pages interface, where we,
>> long-term, would not be able to return non-folio pages (e.g., vm_insert_page())
>> and would instead, in the future, fail the request if we stumble over a
>> non-folio thing in the page tables. That sounds reasonable for now.
> 
> I think whatever we're going to use for direct I/O has to also support
> non-folio pages, especially PCI P2P memory.  So coming up with an
> interface that support this ASAP would be helpful.

Yes.

I think we can keep returning pages as long a the unpin interface knows the
right thing to do to unpin them.

> 
>> Another solution would be, exposing page-ranges (e.g., page + nr_pages), whereby
>> we'd say, that all pages in a range belong to the same compound page, and that
>> we took a single reference for all pages in the range. IOW, page_folio() would
>> for now be the same for all pages in a range.
> 
> This does sound like a reasonable short-term improvement.
Right, and as long as callers don't cast the returned thing to a folio, it would
be future proof. But I guess quite some GUP users cast to folios.

Would there be users for a new interface that returns page ranges as described
above, that would want to still unpin stuff partially? E.g., we give them a page
range that belongs to the same folio with only a single pin/reference, but they
would want to logically split that range and unpin pages individually?

-- 
Cheers,

David