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

[Samiullah Khawaja]

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.
> > 4. A new helper, kho_split_preserved_pages(), is provided for subsystems
> >    that may need to split memory after it has already been preserved.
>
> Umm, that sounds scary... Why do you need to do that? What's the use
> case? Why is the driver reconfiguring its memory after preservation? I
> assume these are DMA buffers, so why do they suddenly look different?
>
> And in either case, why does KHO need to do the split? Why can't the
> driver unpreserve old preservation, then split the pages, and then
> preserve the new ones?
>
> > Considerations
> > ==============
> >
> > 1. A primary goal of this approach is to prevent driver/subsystem code
> >    from peeking into MM internals. Drivers should not need to understand
> >    the distinction between head/tail pages or compound metadata. The KHO
> >    core handles this internally.
> >
> > 2. To handle rare cases where a caller might wish to split a high-order
> >    block after preservation, we provide kho_split_preserved_pages().
> >
> > 3. The callers must ensure that the split_page() doesn't race with
> >    kho_preserve_pages for consistency.
> >
> > 4. Folios are always implicitly considered of the CONTIG type
> >
> > Thanks,
> > Praan
> >
> > [1] https://lore.kernel.org/all/20260505002737.2213734-1-skhawaja@xxxxxxxxxx/
> > [2] https://elixir.bootlin.com/linux/v7.1.1/source/mm/page_alloc.c#L1370
> > [3] https://elixir.bootlin.com/linux/v7.1.1/source/mm/page_alloc.c#L1027
> > [4] https://elixir.bootlin.com/linux/v7.1.1/source/mm/page_alloc.c#L1034
> >
> > Pranjal Shrivastava (4):
> >   kho: Introduce infrastructure to track preserved page types
> >   kho: Detect preserved page types
> >   kho: Implement page-aware refcount restoration
> >   kho: Introduce kho_split_preserved_pages() helper
> >
> >  include/linux/kexec_handover.h     |   7 ++
> >  include/linux/kho_radix_tree.h     |  17 +++-
> >  kernel/liveupdate/kexec_handover.c | 144 +++++++++++++++++++++--------
> >  3 files changed, 124 insertions(+), 44 deletions(-)
> >
> >
> > base-commit: 87320be9f0d24fce67631b7eef919f0b79c3e45c
>
> --
> Regards,
> Pratyush Yadav

Sami