[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@google.com/
>> [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