[PATCH 1/1] liveupdate: kho: calculate per-node scratch sizes before allocation

[PATCH 1/1] liveupdate: kho: calculate per-node scratch sizes before allocation

[George Guo]

From: George Guo <guodongtai@kylinos.cn>

The default percentage-based policy sizes scratch areas from the current
kernel's MEMBLOCK_RSRV_KERN footprint. This is a reasonable heuristic for
predicting the early memory demand of the next kernel.

scratch_size_update() calculates the lowmem and global sizes before either
area is allocated. However, kho_reserve_scratch() calculates each per-node
size only after allocating the lowmem and global areas. Since memblock
allocations are marked MEMBLOCK_RSRV_KERN, the per-node calculation
includes those newly allocated scratch areas and scales them again.

This feedback substantially inflates the per-node request. On a 1 GiB
LoongArch QEMU guest, the relevant reservation baseline is about
98.45 MiB. With the default 200% scale and 32 MiB alignment, the old
ordering allocates 224 MiB of lowmem scratch, then requests 672 MiB for
node 0, for a total of 896 MiB. The node allocation fails and KHO is
disabled. The same incorrect calculation is hidden on the tested 1 GiB
x86 guest because its baseline is smaller and its memory map can satisfy
the inflated request.

Calculate and save all per-node sizes in the scratch descriptors before
reserving any scratch areas, then use the saved sizes during allocation.
This keeps the percentage heuristic while preventing scratch memory from
becoming input to the sizing of more scratch memory. On the LoongArch
guest, the aligned total is reduced from 896 MiB to 448 MiB.

The KHO vmtest passes on 1 GiB LoongArch and x86 QEMU guests with this
change.

Fixes: 3dc92c311498 ("kexec: add Kexec HandOver (KHO) generation helpers")
Reported-by: Kexin Liu <liukexin@kylinos.cn>
Co-developed-by: Kexin Liu <liukexin@kylinos.cn>
Signed-off-by: Kexin Liu <liukexin@kylinos.cn>
Signed-off-by: George Guo <guodongtai@kylinos.cn>
---
 kernel/liveupdate/kexec_handover.c | 13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/kernel/liveupdate/kexec_handover.c b/kernel/liveupdate/kexec_handover.c
index 7c4d86daf86d..39f489a258d9 100644
--- a/kernel/liveupdate/kexec_handover.c
+++ b/kernel/liveupdate/kexec_handover.c
@@ -847,6 +847,17 @@ static void __init kho_reserve_scratch(void)
 		goto err_disable_kho;
 	}
 
+	/*
+	 * Calculate the per-node sizes before reserving any scratch areas.
+	 * memblock allocations are marked MEMBLOCK_RSRV_KERN, so calculating
+	 * them later would count the lowmem and global scratch areas as kernel
+	 * allocations and scale them again.
+	 */
+	i = 2;
+	for_each_node_state(nid, N_MEMORY)
+		kho_scratch[i++].size = scratch_size_node(nid);
+	i = 0;
+
 	/*
 	 * reserve scratch area in low memory for lowmem allocations in the
 	 * next kernel
@@ -880,7 +891,7 @@ static void __init kho_reserve_scratch(void)
 	 * memoryless nodes, as we can not allocate scratch areas there.
 	 */
 	for_each_node_state(nid, N_MEMORY) {
-		size = scratch_size_node(nid);
+		size = kho_scratch[i].size;
 		addr = memblock_alloc_range_nid(size, SCRATCH_ALIGNMENT_BYTES,
 						0, MEMBLOCK_ALLOC_ACCESSIBLE,
 						nid, true);
-- 
2.53.0

Re: [PATCH 1/1] liveupdate: kho: calculate per-node scratch sizes before allocation

[Mike Rapoport]

Hi George,

On Fri, Sep 04, 2026 at 10:51:01AM +0800, George Guo wrote:
> From: George Guo <guodongtai@kylinos.cn>
> 
> The default percentage-based policy sizes scratch areas from the current
> kernel's MEMBLOCK_RSRV_KERN footprint. This is a reasonable heuristic for
> predicting the early memory demand of the next kernel.
> 
> scratch_size_update() calculates the lowmem and global sizes before either
> area is allocated. However, kho_reserve_scratch() calculates each per-node
> size only after allocating the lowmem and global areas. Since memblock
> allocations are marked MEMBLOCK_RSRV_KERN, the per-node calculation
> includes those newly allocated scratch areas and scales them again.
> 
> This feedback substantially inflates the per-node request. On a 1 GiB
> LoongArch QEMU guest, the relevant reservation baseline is about
> 98.45 MiB. With the default 200% scale and 32 MiB alignment, the old
> ordering allocates 224 MiB of lowmem scratch, then requests 672 MiB for
> node 0, for a total of 896 MiB. The node allocation fails and KHO is
> disabled. The same incorrect calculation is hidden on the tested 1 GiB
> x86 guest because its baseline is smaller and its memory map can satisfy
> the inflated request.
> 
> Calculate and save all per-node sizes in the scratch descriptors before
> reserving any scratch areas, then use the saved sizes during allocation.
> This keeps the percentage heuristic while preventing scratch memory from
> becoming input to the sizing of more scratch memory. On the LoongArch
> guest, the aligned total is reduced from 896 MiB to 448 MiB.
> 
> The KHO vmtest passes on 1 GiB LoongArch and x86 QEMU guests with this
> change.

This reads as LLM-generated text. Please add LLM attribution as per 

https://docs.kernel.org/process/coding-assistants.html#attribution
 
> Fixes: 3dc92c311498 ("kexec: add Kexec HandOver (KHO) generation helpers")
> Reported-by: Kexin Liu <liukexin@kylinos.cn>
> Co-developed-by: Kexin Liu <liukexin@kylinos.cn>
> Signed-off-by: Kexin Liu <liukexin@kylinos.cn>
> Signed-off-by: George Guo <guodongtai@kylinos.cn>
> ---
>  kernel/liveupdate/kexec_handover.c | 13 ++++++++++++-
>  1 file changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel/liveupdate/kexec_handover.c b/kernel/liveupdate/kexec_handover.c
> index 7c4d86daf86d..39f489a258d9 100644
> --- a/kernel/liveupdate/kexec_handover.c
> +++ b/kernel/liveupdate/kexec_handover.c
> @@ -847,6 +847,17 @@ static void __init kho_reserve_scratch(void)
>  		goto err_disable_kho;
>  	}
>  
> +	/*
> +	 * Calculate the per-node sizes before reserving any scratch areas.
> +	 * memblock allocations are marked MEMBLOCK_RSRV_KERN, so calculating
> +	 * them later would count the lowmem and global scratch areas as kernel
> +	 * allocations and scale them again.
> +	 */
> +	i = 2;
> +	for_each_node_state(nid, N_MEMORY)
> +		kho_scratch[i++].size = scratch_size_node(nid);
> +	i = 0;

Ugh, this really does not look nice.
Can't we just calculated all the sizes first and than do the allocations?

> +
>  	/*
>  	 * reserve scratch area in low memory for lowmem allocations in the
>  	 * next kernel
> @@ -880,7 +891,7 @@ static void __init kho_reserve_scratch(void)
>  	 * memoryless nodes, as we can not allocate scratch areas there.
>  	 */
>  	for_each_node_state(nid, N_MEMORY) {
> -		size = scratch_size_node(nid);
> +		size = kho_scratch[i].size;
>  		addr = memblock_alloc_range_nid(size, SCRATCH_ALIGNMENT_BYTES,
>  						0, MEMBLOCK_ALLOC_ACCESSIBLE,
>  						nid, true);
> -- 
> 2.53.0
> 

-- 
Sincerely yours,
Mike.

Re: [PATCH 1/1] liveupdate: kho: calculate per-node scratch sizes before allocation

[George Guo]

Hi Mike,

> This reads as LLM-generated text. Please add LLM attribution as per
>
> https://docs.kernel.org/process/coding-assistants.html#attribution

I'll add the Assisted-by tag.

> Can't we just calculated all the sizes first and than do the allocations?

Yes, I'll rework this to calculate all scratch sizes together before
allocating the scratch areas.

Adding Sourabh to Cc, since this relates to the scratch-sizing discussion
in the PowerPC KHO thread.

Sourabh, this patch prevents newly allocated scratch areas from being
counted in the per-node baseline. It does not address the overlap between
global and per-node accounting. Could you review this approach as well?

Thanks,
George