[RFC PATCH 0/4] kho: Support preserving unsplit high-order pages
Mike Rapoport
rppt at kernel.org
Thu Jul 9 04:00:12 PDT 2026
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:
> >>
> >> 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? :-)
Thank you for the compliment, but I'm drawing blank on this one :)
The best I could come up with is to kho_preserve_page_range() for order-0
pages.
> > 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.
Right, preserving compound pages is more similar to preserving folios
actually.
> --
> Regards,
> Pratyush Yadav
--
Sincerely yours,
Mike.
More information about the kexec
mailing list