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

[Mike Rapoport]

On Sat, Jul 25, 2026 at 07:21:00PM +0200, Pratyush Yadav wrote:
> From: "Pratyush Yadav (Google)" <pratyush@xxxxxxxxxx>
> 
> 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.

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

-- 
Sincerely yours,
Mike.