On Tue, Dec 23 2025, Pasha Tatashin wrote: > On Sat, Dec 6, 2025 at 6:03 PM Pratyush Yadav <[email protected]> wrote: >> >> KHO currently restricts the maximum order of a restored page to the >> maximum order supported by the buddy allocator. While this works fine >> for much of the data passed across kexec, it is possible to have pages >> larger than MAX_PAGE_ORDER. >> >> For one, it is possible to get a larger order when using >> kho_preserve_pages() if the number of pages is large enough, since it >> tries to combine multiple aligned 0-order preservations into one higher >> order preservation. >> >> For another, upcoming support for hugepages can have gigantic hugepages >> being preserved over KHO. >> >> There is no real reason for this limit. The KHO preservation machinery >> can handle any page order. Remove this artificial restriction on max >> page order. > > Before removing this restriction, please also add a patch that makes > sure that the calculated order does not intermix memory from different > topologies. > > I suspect we need something like this in kho_preserve_pages(): > > order = min(count_trailing_zeros(pfn), ilog2(end_pfn - pfn)); > /* Reduce order if the block spans across NUMA nodes. */ > while (order > 0) { > size_pfn = 1UL << order; > if (pfn_to_nid(pfn) == pfn_to_nid(pfn + size_pfn - 1)) > break; > order--; > }
ACK. Will do. And I think I will split it out of the HugeTLB series since I think this can be applied independently. -- Regards, Pratyush Yadav
