Re: [PATCH v3 19/21] memblock: make HugeTLB bootmem allocation work with KHO

[Pratyush Yadav <pratyush@kernel.org>]

On Wed, Jul 15 2026, Mike Rapoport wrote:

>> Gigantic huge page allocation is somewhat broken currently when KHO is
>> used.
>> 
>> Firstly, they break KHO scratch size accounting. RSRV_KERN is used to
>> track how much memory is reserved for use by the kernel. Since
>> hugetlb::alloc_bootmem() calls the memblock_alloc*() APIs, the hugepages
>> allocated also get marked as RSRV_KERN.
>> 
>> Allocations marked RSRV_KERN are used by KHO to calculate how much
>> scratch space it should reserve to make sure the next kernel has enough
>> memory to boot when it is in scratch-only phase. Counting hugepages in
>> that blows up scratch size, and can lead to the scratch allocation
>> failing, making KHO unusable. This will show up when huge pages make up
>> more than 50% of the system, which is a fairly common use case.
>> 
>> Secondly, while not supported right now, huge pages are user memory and
>> can be preserved via KHO. The scratch spaces should not have any
>> preserved memory. Allocating hugepages from scratch (on a KHO boot) can
>> lead to them being un-preservable.
>> 
>> Introduce memblock_alloc_hugetlb(). This lets memblock tailor to the
>> needs of hugetb without exposing those details to the general allocation
>> routines.
>> 
>> First, it does not use mirrored memory for hugetlb. Mirrored memory is a
>> limited resource that is best saved for kernel data structures, not user
>> memory.
>> 
>> Second, if the free memory area found by memblock_find_in_range_node()
>> is a part of a KHO scratch area, the free area is not used. Allocation
>> is retried starting after the free area to ensure no hugepages come from
>> KHO scratch.
>> 
>> Third, it simplifies the argument list by baking in some hugetlb
>> assumptions like alignment and exact_nid. This also simplifies
>> allocation logic in alloc_bootmem().
>> 
>> Also introduce MEMBLOCK_RSRV_HUGETLB to mark reservations made for
>> HugeTLB. This will be used by KHO in future patches to correctly
>> calculate scratch sizes.
>> 
>> Refactor some of the preparation logic like kmemleak tracking and
>> accepting memory into a separate helper memblock_prep_allocation(), and
>> use it from both memblock_alloc_hugetlb() and the usual
>> memblock_alloc_range_nid().
>> 
>> Add a stub for kho_scratch_overlap to memblock tests to make sure it
>> compiles.
>> 
>> Signed-off-by: Pratyush Yadav (Google) <pratyush@kernel.org>
[...]
>> diff --git a/mm/memblock.c b/mm/memblock.c
>> index 8b2e551435ae9..ba6d887ea18eb 100644
>> --- a/mm/memblock.c
>> +++ b/mm/memblock.c
>> @@ -1506,6 +1506,32 @@ int __init_memblock memblock_set_node(phys_addr_t base, phys_addr_t size,
>>  	return 0;
>>  }
>>  
>> +static void memblock_prep_allocation(phys_addr_t start, phys_addr_t size,
>> +				     bool leaktrace)
>
> Let's call this kmemleak_trace

ACK.

>
>> +{
>> +	/*
>> +	 * Skip kmemleak for those places like kasan_init() and
>> +	 * early_pgtable_alloc() due to high volume.
>> +	 */
>> +	if (leaktrace)
>> +		/*
>> +		 * Memblock allocated blocks are never reported as
>> +		 * leaks. This is because many of these blocks are
>> +		 * only referred via the physical address which is
>> +		 * not looked up by kmemleak.
>> +		 */
>> +		kmemleak_alloc_phys(start, size, 0);
[...]
>> diff --git a/tools/testing/memblock/internal.h b/tools/testing/memblock/internal.h
>> index b6b1d147fd750..e86bb9000b22f 100644
>> --- a/tools/testing/memblock/internal.h
>> +++ b/tools/testing/memblock/internal.h
>> @@ -66,4 +66,9 @@ static inline void init_deferred_page(unsigned long pfn, int nid)
>>  
>>  #define __SetPageReserved(p)	((void)(p))
>>  
>> +static inline bool kho_scratch_overlap(phys_addr_t phys, size_t size)
>> +{
>> +	return false;
>> +}
>> +
>
> This should be in the patch that exposes kho_scratch_overlap() to kexec_handover.h

Hm, sure, why not. I added it here because _this patch_ uses
kho_scratch_overlap() for the first time on memblock.c, and with that
breaks build of the memblock tests. So I recokned it makes sense to have
it in the place that broke it.

But I don't mind, I can move it to the other patch as well.

-- 
Regards,
Pratyush Yadav