Re: [PATCH v4 2/2] kho: Introduce preserve/restore APIs for high-order pages
Pranjal Shrivastava <[email protected]>
| Newsgroups | org.infradead.lists.kexec,org.kernel.vger.linux-kernel,org.kvack.linux-mm |
|---|---|
| Message-ID | <[email protected]> |
On Wed, Aug 12, 2026 at 01:10:23PM +0200, Pratyush Yadav wrote: > On Mon, Aug 03 2026, Pranjal Shrivastava wrote: > > > The current KHO page preservation APIs (e.g. kho_preserve_pages) assume > > that multi-page blocks are split into independent 4KB pages during > > restoration. This is incompatible with high-order non-compound pages, > > such as DMA buffers, which must be restored with tail pages having a > > zero reference count. > > > > Introduce explicit preserve and restore APIs for high-order pages, > > which preserve and restore a high-order page block as a single unit, > > applying a refcount of 1 to the head page while leaving tail pages at 0. > > Rename the existing internal helper to __kho_restore_page() and > > consolidate the common restoration code into it. > > > > Signed-off-by: Pranjal Shrivastava <[email protected]> > > The code here looks very convoluted TBH. I think it will be simpler to > make kho_restore_page() only return non-compound pages. That is, it > returns 0 or higher order non-compound page. > > Then kho_restore_pages() can call kho_restore_page() and then do > split_page() on the page it got to turn it into 0-order pages. > kho_restore_folio() can call kho_restore_page() and then do > prep_compound_page() on the page it got. > > And then you expose kho_restore_page() to be used by DMA APIs to get > non-compound high order pages directly. > > How does that sound? > I like the suggestion to use a single base primitive and mold it via split_page() and prep_compound_page(). However, To implement this, we'll need __kho_restore_page(phys, &order) as the internal base primitive because callers (like kho_restore_folio) need to retrieve the order from the KHO metadata to pass into prep_compound_page(), and a raw non-compound struct page doesn't store its order. By having __kho_restore_page() initialize the head_ref = 1 & all_tails =0 refcount pattern by default, all three public APIs can just wrap it and call the appropriate MM subsystem helpers. I'll spin v5 with this Thanks, Praan