[RFC PATCH 0/4] kho: Support preserving unsplit high-order pages

[Pratyush Yadav]

On Wed, Jul 08 2026, Pranjal Shrivastava wrote:

> On Wed, Jul 08, 2026 at 04:36:46PM +0000, Samiullah Khawaja wrote:
>> On Wed, Jul 08, 2026 at 04:11:04PM +0200, Pratyush Yadav wrote:
>> > On Fri, Jul 03 2026, Pranjal Shrivastava wrote:
>> > 
>> 
>> [snip]
>> > > 
>> > > 3. kho_restore_page() applies the correct refcount pattern based on the
>> > >    preserved metadata.
>> > 
>> > Why do you need to save the type of pages in KHO metadata? For example,
>> > for pages or folios, we don't store any type information and leave it to
>> > the caller choose the right API. So reserve-mem and kho vmalloc need
>> > pages, they can call kho_{preserve,restore}_pages(), and memfd needs
>> > folios so it can call kho_{preserve,restore}_folio(). The radix tree
>> > itself does not hold the information. The caller knows what its memory
>> > is supposed to be so it calls the right restore API.
>> > 
>> > So why can't we add a kho_{preserve,restore}_page_multi() (pick a better
>> > name; we can argue about the naming later)? Then your driver knows it is
>> > restoring DMA buffers so it can call kho_restore_page_multi(), and KHO
>> > takes care of initializing the pages with the right refcounts.
>> > 
>> > You won't have to muck about with the ABI in that case.
>> 
>> +1
>> 
>> I think this makes sense. The mm already relies on the allocator to
>> track the type of pages it has and expectes it to use free_pages or
>> put_page() or free_page(), so it is natural for KHO to rely on the
>> caller to call the right restore API.
>> 
>> Lets add kho_preserve/restore_page_contig|_order|_nonsplit and the dma
>> preservation can use the appropriate one during restore.
>
> Ack. I like kho_restore_contig, I don't think we'll need a preserve for

Dunno, everything is contiguous, folio, 0-order pages, higher order
pages. So not exactly the best name.

Since you'd get these pages via alloc_pages, perhaps
kho_preserve_pages() works better for this kind of allocation, and for
the _current_ kho_preserve_pages(), we can rename it to
kho_preserve_split_pages()? It is a bit too wordy though, so that's a
downside.

Mike, you are better than me at naming things, so do you perhaps have
any better ideas? :-)

> this though? Preserve doesn't seem to be preserving refcounts, I guess
> we could rely on kho_preserve_pages and the caller can use
> kho_restore_pages_contig() to set refcount correctly for unsplit pages?

No, kho_preserve_pages() can split the preservations in unexpected ways.
While for a high order pages the current algorithm _shouldn't_ do it, it
is simpler to just add a new preservation function.

Move things out into helpers if you want to avoid duplication, though at
first glance I don't think there should be much.

-- 
Regards,
Pratyush Yadav