[PATCH 1/2] kho: make sure preservations do not span multiple NUMA nodes

[PATCH 1/2] kho: make sure preservations do not span multiple NUMA nodes

[Pratyush Yadav]

From: "Pratyush Yadav (Google)" <pratyush@kernel.org>

The KHO restoration machinery is not capable of dealing with
preservations that span multiple NUMA nodes. kho_preserve_folio()
guarantees the preservation will only span one NUMA node since folios
can't span multiple nodes.

This leaves kho_preserve_pages(). While semantically
kho_preserve_pages() only deals with 0-order pages, so all preservations
should be single page only, in practice it combines preservations to
higher orders for efficiency. This can result in a preservation spanning
multiple nodes. Break up the preservations into a smaller order if that
happens.

Suggested-by: Pasha Tatashin <pasha.tatashin@soleen.com>
Signed-off-by: Pratyush Yadav (Google) <pratyush@kernel.org>
---

Notes:
    Ref: https://lore.kernel.org/linux-mm/CA+CK2bDvaGmfkCPCMWM6gPcd4FfUyD6e5yWE+kNcma1vT3Jw3g@mail.gmail.com/

 kernel/liveupdate/kexec_handover.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/kernel/liveupdate/kexec_handover.c b/kernel/liveupdate/kexec_handover.c
index cc68a3692905..bc9bd18294ee 100644
--- a/kernel/liveupdate/kexec_handover.c
+++ b/kernel/liveupdate/kexec_handover.c
@@ -869,9 +869,17 @@ int kho_preserve_pages(struct page *page, unsigned long nr_pages)
 	}
 
 	while (pfn < end_pfn) {
-		const unsigned int order =
+		unsigned int order =
 			min(count_trailing_zeros(pfn), ilog2(end_pfn - pfn));
 
+		/*
+		 * Make sure all the pages in a single preservation are in the
+		 * same NUMA node. The restore machinery can not cope with a
+		 * preservation spanning multiple NUMA nodes.
+		 */
+		while (pfn_to_nid(pfn) != pfn_to_nid(pfn + (1UL << order) - 1))
+			order--;
+
 		err = __kho_preserve_order(track, pfn, order);
 		if (err) {
 			failed_pfn = pfn;
-- 
2.53.0.473.g4a7958ca14-goog

[PATCH 2/2] kho: drop restriction on maximum page order

[Pratyush Yadav]

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.

Signed-off-by: Pratyush Yadav <pratyush@kernel.org>
Signed-off-by: Pratyush Yadav (Google) <pratyush@kernel.org>
---

Notes:
    This patch was first sent with this RFC series [0]. I am sending it
    separately since it is an independent patch that is useful even without
    hugepage preservation. No changes since the RFC.
    
    [0] https://lore.kernel.org/linux-mm/20251206230222.853493-1-pratyush@kernel.org/T/#u

 kernel/liveupdate/kexec_handover.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/liveupdate/kexec_handover.c b/kernel/liveupdate/kexec_handover.c
index bc9bd18294ee..1038e41ff9f9 100644
--- a/kernel/liveupdate/kexec_handover.c
+++ b/kernel/liveupdate/kexec_handover.c
@@ -253,7 +253,7 @@ static struct page *kho_restore_page(phys_addr_t phys, bool is_folio)
 	 * check also implicitly makes sure phys is order-aligned since for
 	 * non-order-aligned phys addresses, magic will never be set.
 	 */
-	if (WARN_ON_ONCE(info.magic != KHO_PAGE_MAGIC || info.order > MAX_PAGE_ORDER))
+	if (WARN_ON_ONCE(info.magic != KHO_PAGE_MAGIC))
 		return NULL;
 	nr_pages = (1 << info.order);
 
-- 
2.53.0.473.g4a7958ca14-goog

Re: [PATCH 1/2] kho: make sure preservations do not span multiple NUMA nodes

[Samiullah Khawaja]

On Mon, Mar 09, 2026 at 12:34:06PM +0000, Pratyush Yadav wrote:
>From: "Pratyush Yadav (Google)" <pratyush@kernel.org>
>
>The KHO restoration machinery is not capable of dealing with
>preservations that span multiple NUMA nodes. kho_preserve_folio()
>guarantees the preservation will only span one NUMA node since folios
>can't span multiple nodes.
>
>This leaves kho_preserve_pages(). While semantically
>kho_preserve_pages() only deals with 0-order pages, so all preservations
>should be single page only, in practice it combines preservations to
>higher orders for efficiency. This can result in a preservation spanning
>multiple nodes. Break up the preservations into a smaller order if that
>happens.
>
>Suggested-by: Pasha Tatashin <pasha.tatashin@soleen.com>
>Signed-off-by: Pratyush Yadav (Google) <pratyush@kernel.org>
>---
>
>Notes:
>    Ref: https://lore.kernel.org/linux-mm/CA+CK2bDvaGmfkCPCMWM6gPcd4FfUyD6e5yWE+kNcma1vT3Jw3g@mail.gmail.com/
>
> kernel/liveupdate/kexec_handover.c | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
>diff --git a/kernel/liveupdate/kexec_handover.c b/kernel/liveupdate/kexec_handover.c
>index cc68a3692905..bc9bd18294ee 100644
>--- a/kernel/liveupdate/kexec_handover.c
>+++ b/kernel/liveupdate/kexec_handover.c
>@@ -869,9 +869,17 @@ int kho_preserve_pages(struct page *page, unsigned long nr_pages)
> 	}
>
> 	while (pfn < end_pfn) {
>-		const unsigned int order =
>+		unsigned int order =
> 			min(count_trailing_zeros(pfn), ilog2(end_pfn - pfn));
>
>+		/*
>+		 * Make sure all the pages in a single preservation are in the
>+		 * same NUMA node. The restore machinery can not cope with a
>+		 * preservation spanning multiple NUMA nodes.
>+		 */
>+		while (pfn_to_nid(pfn) != pfn_to_nid(pfn + (1UL << order) - 1))
>+			order--;
>+
> 		err = __kho_preserve_order(track, pfn, order);
> 		if (err) {
> 			failed_pfn = pfn;
>-- 
>2.53.0.473.g4a7958ca14-goog
>
>

Reviewed-by: Samiullah Khawaja <skhawaja@google.com>

Re: [PATCH 1/2] kho: make sure preservations do not span multiple NUMA nodes

[Mike Rapoport]

On Mon, Mar 09, 2026 at 12:34:06PM +0000, Pratyush Yadav wrote:
> From: "Pratyush Yadav (Google)" <pratyush@kernel.org>
> 
> The KHO restoration machinery is not capable of dealing with
> preservations that span multiple NUMA nodes. kho_preserve_folio()
> guarantees the preservation will only span one NUMA node since folios
> can't span multiple nodes.
> 
> This leaves kho_preserve_pages(). While semantically
> kho_preserve_pages() only deals with 0-order pages, so all preservations
> should be single page only, in practice it combines preservations to
> higher orders for efficiency. This can result in a preservation spanning
> multiple nodes. Break up the preservations into a smaller order if that
> happens.
> 
> Suggested-by: Pasha Tatashin <pasha.tatashin@soleen.com>
> Signed-off-by: Pratyush Yadav (Google) <pratyush@kernel.org>

Reviewed-by: Mike Rapoport (Microsoft) <rppt@kernel.org>

> ---
> 
> Notes:
>     Ref: https://lore.kernel.org/linux-mm/CA+CK2bDvaGmfkCPCMWM6gPcd4FfUyD6e5yWE+kNcma1vT3Jw3g@mail.gmail.com/
> 
>  kernel/liveupdate/kexec_handover.c | 10 +++++++++-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel/liveupdate/kexec_handover.c b/kernel/liveupdate/kexec_handover.c
> index cc68a3692905..bc9bd18294ee 100644
> --- a/kernel/liveupdate/kexec_handover.c
> +++ b/kernel/liveupdate/kexec_handover.c
> @@ -869,9 +869,17 @@ int kho_preserve_pages(struct page *page, unsigned long nr_pages)
>  	}
>  
>  	while (pfn < end_pfn) {
> -		const unsigned int order =
> +		unsigned int order =
>  			min(count_trailing_zeros(pfn), ilog2(end_pfn - pfn));
>  
> +		/*
> +		 * Make sure all the pages in a single preservation are in the
> +		 * same NUMA node. The restore machinery can not cope with a
> +		 * preservation spanning multiple NUMA nodes.
> +		 */
> +		while (pfn_to_nid(pfn) != pfn_to_nid(pfn + (1UL << order) - 1))
> +			order--;
> +
>  		err = __kho_preserve_order(track, pfn, order);
>  		if (err) {
>  			failed_pfn = pfn;
> -- 
> 2.53.0.473.g4a7958ca14-goog
> 

-- 
Sincerely yours,
Mike.

Re: [PATCH 2/2] kho: drop restriction on maximum page order

[Mike Rapoport]

On Mon, Mar 09, 2026 at 12:34:07PM +0000, Pratyush Yadav 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.
> 
> Signed-off-by: Pratyush Yadav <pratyush@kernel.org>
> Signed-off-by: Pratyush Yadav (Google) <pratyush@kernel.org>

One SOB should be enough ;-)

Reviewed-by: Mike Rapoport (Microsoft) <rppt@kernel.org>

> ---
> 
> Notes:
>     This patch was first sent with this RFC series [0]. I am sending it
>     separately since it is an independent patch that is useful even without
>     hugepage preservation. No changes since the RFC.
>     
>     [0] https://lore.kernel.org/linux-mm/20251206230222.853493-1-pratyush@kernel.org/T/#u
> 
>  kernel/liveupdate/kexec_handover.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/kernel/liveupdate/kexec_handover.c b/kernel/liveupdate/kexec_handover.c
> index bc9bd18294ee..1038e41ff9f9 100644
> --- a/kernel/liveupdate/kexec_handover.c
> +++ b/kernel/liveupdate/kexec_handover.c
> @@ -253,7 +253,7 @@ static struct page *kho_restore_page(phys_addr_t phys, bool is_folio)
>  	 * check also implicitly makes sure phys is order-aligned since for
>  	 * non-order-aligned phys addresses, magic will never be set.
>  	 */
> -	if (WARN_ON_ONCE(info.magic != KHO_PAGE_MAGIC || info.order > MAX_PAGE_ORDER))
> +	if (WARN_ON_ONCE(info.magic != KHO_PAGE_MAGIC))
>  		return NULL;
>  	nr_pages = (1 << info.order);
>  
> -- 
> 2.53.0.473.g4a7958ca14-goog
> 

-- 
Sincerely yours,
Mike.

Re: [PATCH 2/2] kho: drop restriction on maximum page order

[Pratyush Yadav]

On Tue, Mar 10 2026, Mike Rapoport wrote:

> On Mon, Mar 09, 2026 at 12:34:07PM +0000, Pratyush Yadav 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.
>> 
>> Signed-off-by: Pratyush Yadav <pratyush@kernel.org>
>> Signed-off-by: Pratyush Yadav (Google) <pratyush@kernel.org>
>
> One SOB should be enough ;-)

Hmm, I figured the unemployed me (who originally wrote the patch) and
the employed-by-google me (who is doing this new version) would count as
two separate entities and there should be a S-o-b for both.

Anyway, I am fine with dropping either one of the two.

>
> Reviewed-by: Mike Rapoport (Microsoft) <rppt@kernel.org>

Thanks!

[...]

-- 
Regards,
Pratyush Yadav

Re: [PATCH 2/2] kho: drop restriction on maximum page order

[Mike Rapoport]

On Tue, Mar 17, 2026 at 09:12:19AM +0000, Pratyush Yadav wrote:
> On Tue, Mar 10 2026, Mike Rapoport wrote:
> 
> > On Mon, Mar 09, 2026 at 12:34:07PM +0000, Pratyush Yadav 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.
> >> 
> >> Signed-off-by: Pratyush Yadav <pratyush@kernel.org>
> >> Signed-off-by: Pratyush Yadav (Google) <pratyush@kernel.org>
> >
> > One SOB should be enough ;-)
> 
> Hmm, I figured the unemployed me (who originally wrote the patch) and
> the employed-by-google me (who is doing this new version) would count as
> two separate entities and there should be a S-o-b for both.

Maybe than something like:

Signed-off-by: Pratyush Yadav (Hobbyist) <pratyush@kernel.org>
Signed-off-by: Pratyush Yadav (Google) <pratyush@kernel.org>
 
;-)

> Anyway, I am fine with dropping either one of the two.
> 
> >
> > Reviewed-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
> 
> Thanks!
> 
> [...]
> 
> -- 
> Regards,
> Pratyush Yadav

-- 
Sincerely yours,
Mike.

Re: [PATCH 2/2] kho: drop restriction on maximum page order

[Pratyush Yadav]

On Tue, Mar 17 2026, Mike Rapoport wrote:

> On Tue, Mar 17, 2026 at 09:12:19AM +0000, Pratyush Yadav wrote:
>> On Tue, Mar 10 2026, Mike Rapoport wrote:
>> 
>> > On Mon, Mar 09, 2026 at 12:34:07PM +0000, Pratyush Yadav 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.
>> >> 
>> >> Signed-off-by: Pratyush Yadav <pratyush@kernel.org>
>> >> Signed-off-by: Pratyush Yadav (Google) <pratyush@kernel.org>
>> >
>> > One SOB should be enough ;-)
>> 
>> Hmm, I figured the unemployed me (who originally wrote the patch) and
>> the employed-by-google me (who is doing this new version) would count as
>> two separate entities and there should be a S-o-b for both.
>
> Maybe than something like:
>
> Signed-off-by: Pratyush Yadav (Hobbyist) <pratyush@kernel.org>
> Signed-off-by: Pratyush Yadav (Google) <pratyush@kernel.org>
>  
> ;-)
>
Yeah, that works too :-)

I'll use that when I redo some of the HugeTLB patches too

-- 
Regards,
Pratyush Yadav