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@xxxxxxxxxx>
> 
> 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@xxxxxxxxxx>
> Co-developed-by: Kexin Liu <liukexin@xxxxxxxxxx>
> Signed-off-by: Kexin Liu <liukexin@xxxxxxxxxx>
> Signed-off-by: George Guo <guodongtai@xxxxxxxxxx>
> ---
>  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.