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

[Pranjal Shrivastava <praan@google.com>]

On Wed, Jul 08, 2026 at 07:34:20PM +0200, Pratyush Yadav wrote:
> 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.
> 

I suppose this is to preserve unsplit higher order non-compound pages.
kho_preserve_unsplit_pages() ? 

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

+1 would love everyone's help here :)

> > 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.

Ack, I'll add another preserve helper.

> 
> -- 
> Regards,
> Pratyush Yadav

Thanks,
Praan