Re: [RFC v1] io_uring/rsrc: add fast path huge page handling in buffer registration
"David Hildenbrand (Arm)" <[email protected]>
| Newsgroups | org.kernel.vger.io-uring,org.kernel.vger.linux-kernel,org.kvack.linux-mm |
|---|---|
| Message-ID | <[email protected]> |
On 6/10/26 08:16, Christoph Hellwig wrote: > On Tue, Jun 09, 2026 at 08:36:43PM +0200, David Hildenbrand (Arm) wrote: >> I really don't like arbitrary GUP users to starting to special case hugetlb >> folios, and making assumptions of how other pages they pinned look like (IOW, >> how the page table mappings actually looked like). > > Me neither, but the current interfaces are kind forcing them :P Yeah :) But general rule: if you're outside of MM core and test for hugetlb folios, you are doing something very wrong. > >> >> Ideally, we'd have a pin_user_pages_fast() variant that would give you a list of >> folio ranges instead of individual pages. > > 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. 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. 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. As soon as some mapped pages are no longer folios, we'll likely have to modify plenty of drivers either way, that blindly cast pages to folios ... So maybe a folio-range based interface is good enough for now. -- Cheers, David