Re: [PATCH v4 00/21] kho: make boot time huge page allocation work nicely with KHO

[Pratyush Yadav <pratyush@kernel.org>]

On Tue, Jul 28 2026, Mike Rapoport wrote:

> On Sat, Jul 25, 2026 at 07:21:00PM +0200, Pratyush Yadav wrote:
>> From: "Pratyush Yadav (Google)" <pratyush@kernel.org>
>> 
>> Hi,
>> 
>> Gigantic huge page allocation is somewhat broken currently with KHO.
>> 
>> First, they break scratch size accounting. Since they are allocated
>> using the memblock alloc APIs, they count towards RSRV_KERN, and this
>> scratch size when using scratch_scale. This means if huge pages take a
>> large enough chunk of system memory scratch size will blow up and fail
>> to allocate.
>> 
>> Second, scratch can not contain preserved memory, and if hugepages are
>> allocated from scratch, they will fail to be preserved with the upcoming
>> hugetlb preservation series [0].
>> 
>> Fix this by introducing the concept of extended scratch areas. They are
>> areas that the kernel discovers on boot by walking the radix tree and
>> finding free memory ranges. See patch 10 for more details.
>> 
>> Muchun Song (1):
>>   mm/mm_init: simplify deferred_free_pages() migratetype init
>> 
>> Pratyush Yadav (Google) (20):
>>   kho: generalize radix tree APIs
>>   kho: make radix max key width more obvious
>>   kho: disallow wide keys in radix tree
>>   kho: return virtual address of mem_map from kho_get_mem_map()
>>   kho: store incoming radix tree in kho_in
>>   kho: move all memory retrieval logic to kho_mem_retrieve()
>>   kho: add a struct for radix callbacks
>>   kho: add callback for table pages
>>   kho: add data argument to radix walk callback
>>   kho: allow early-boot usage of the KHO radix tree
>>   kho: allow destroying KHO radix tree
>>   kho: add kho_radix_init_tree()
>>   kho: expose kho_scratch_overlap() to kexec_handover.h
>>   kho: initialize kho_scratch pointer earlier in boot
>>   kho: initialize preserved memory map radix tree earlier
>>   mm/mm_init: don't rely on memblock to get KHO scratch migratetype
>>   kho: extend scratch
>>   memblock: make HugeTLB bootmem allocation work with KHO
>>   memblock: add memblock_reserved_hugetlb_size()
>>   kho: exclude hugetlb memory from scratch size calculation
>
> I added it to the liveupdate tree.

Thanks!

>
> Please take a look at Sashiko comments, we might need v5 if it has valid
> (not pre-existing) points.

I took a quick look and the only valid points I can see are the ones on
patch 19/21 "memblock: make HugeTLB bootmem allocation work with KHO".

All others are pre-existing problems.

Is it okay if I send a single follow up patch to fix 19/21? Or would you
prefer a full respin?

Also, general thing, but I should go and fix all the pre-existing
problems too at some point. I sent a fix for a really simple one
already, but Sashiko has found other problems too...

-- 
Regards,
Pratyush Yadav