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 20:10, Matthew Wilcox wrote: > On Wed, Jun 10, 2026 at 03:18:52PM +0200, David Hildenbrand (Arm) wrote: >> On 6/10/26 13:34, Christoph Hellwig wrote: >>> >>> 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. > > This would be the get_user_phyrs() interface I've talked about before. > > https://lore.kernel.org/all/[email protected]/ > and the long thread: > https://lore.kernel.org/all/[email protected]/ > >> 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? > > Urgh, no, we shouldn't do that. ranges should be pinned / unpinned > as a whole. I'm sympathetic to "for this special operation we need to > create a new range from this existing range and adjust the refcount(s) > appropriately so each of the two rangees can be put separately", but > I'm not sympathetic to "we need to allow each page to be individually > refcounted". Yes, me too. I wanted to understand if that a common thing to happen for users, such that we would have to worry about it right from the start. -- Cheers, David