Re: [PATCH] kho: always print scratch sizes

[Pratyush Yadav <pratyush@kernel.org>]

On Thu, May 21 2026, Pasha Tatashin wrote:

> On 05-19 17:53, Pratyush Yadav wrote:
>> From: "Pratyush Yadav (Google)" <pratyush@kernel.org>
>> 
>> Currently, KHO only prints scratch sizes when the size is specified
>> by the command line. It prints nothing when the size is calculated
>> at runtime by counting RSRV_KERN.
>> 
>> These prints are completely useless. When the user specified the size on
>> the command line, they already know how large the scratch areas are. And
>> that information is readily available by looking at the command line. It
>> is a lot more useful to know the sizes that are calculated at runtime
>> since they can vary by kernel version. Plus, if KHO fails to allocate
>> the scratch areas, the calculated scratch sizes are not available via
>> debugfs.
>> 
>> Print the scratch sizes in kho_reserve_scratch(). Do it before making
>> the allocations. The size can provide hints for the failure reason.
>> 
>> Signed-off-by: Pratyush Yadav (Google) <pratyush@kernel.org>
>> ---
>>  kernel/liveupdate/kexec_handover.c | 12 +++++++-----
>>  1 file changed, 7 insertions(+), 5 deletions(-)
>> 
>> diff --git a/kernel/liveupdate/kexec_handover.c b/kernel/liveupdate/kexec_handover.c
>> index 33fcf848ef95..b030f53f2235 100644
>> --- a/kernel/liveupdate/kexec_handover.c
>> +++ b/kernel/liveupdate/kexec_handover.c
>> @@ -621,11 +621,6 @@ static int __init kho_parse_scratch_size(char *p)
>>  	scratch_size_pernode = sizes[2];
>>  	scratch_scale = 0;
>>  
>> -	pr_notice("scratch areas: lowmem: %lluMiB global: %lluMiB pernode: %lldMiB\n",
>> -		  (u64)(scratch_size_lowmem >> 20),
>> -		  (u64)(scratch_size_global >> 20),
>> -		  (u64)(scratch_size_pernode >> 20));
>> -
>>  	return 0;
>>  }
>>  early_param("kho_scratch", kho_parse_scratch_size);
>> @@ -691,6 +686,10 @@ static void __init kho_reserve_scratch(void)
>>  		goto err_disable_kho;
>>  	}
>>  
>> +	pr_notice("scratch areas: lowmem: %lluMiB global: %lluMiB\n",
>> +		  (u64)(scratch_size_lowmem >> 20),
>> +		  (u64)(scratch_size_global >> 20));
>> +
>>  	/*
>>  	 * reserve scratch area in low memory for lowmem allocations in the
>>  	 * next kernel
>> @@ -725,6 +724,9 @@ static void __init kho_reserve_scratch(void)
>>  	 */
>>  	for_each_node_state(nid, N_MEMORY) {
>>  		size = scratch_size_node(nid);
>> +
>> +		pr_notice("scratch_areas: nid %d: %lluMiB\n", nid, size >> 20);
>
> Please use a space instead of an underscore to match the other string: 
> "scratch areas". Keeping the prefix identical makes log parsing and 
> filtering much cleaner.

Sure, will do.

>
> Unrelated to this patch—this is something I brought up to Pratyush off-list, 
> but I really dislike the 'KHO scratch' terminology.
>
> First, it isn't actually 'scratch' space, as the kernel relies on it to 
> allocate crucial early boot memory, which it then uses permanently. 
> Second, we cannot preserve anything within this specific region. 
>
> Down the line, I'd like to rename this to something more descriptive that clearly 
> conveys both its importance to early boot and its non-preservable nature. For 
> now, the print adjustments themselves look good.
>
> I do not know it should be, but something like kho_bootstrap area sounds 
> better than kho_sratch area.

Sure. I think we can land this patch now, and then update the string
when we agree on a better name. But I won't mind waiting either if you
want to reduce churn.

>
>> +
>>  		addr = memblock_alloc_range_nid(size, CMA_MIN_ALIGNMENT_BYTES,
>>  						0, MEMBLOCK_ALLOC_ACCESSIBLE,
>>  						nid, true);
>> 
>> base-commit: 34e8f02817e31826e76bb2ded48bf28fe921f20b
>> -- 
>> 2.54.0.563.g4f69b47b94-goog
>> 

-- 
Regards,
Pratyush Yadav