Re: [PATCH 12/12] mm/hugetlb: make bootmem allocation work with KHO

[Pratyush Yadav <pratyush@kernel.org>]

On Sun, May 31 2026, Mike Rapoport wrote:

> On Mon, May 25, 2026 at 05:24:09PM +0200, Pratyush Yadav wrote:
>> On Sun, May 17 2026, Mike Rapoport wrote:
>> > On Wed, Apr 29, 2026 at 03:39:14PM +0200, Pratyush Yadav wrote:
>> >> From: "Pratyush Yadav (Google)" <pratyush@kernel.org>
>> 
>> So, in summary, I would like to pursue option 1 and try to make it more
>> appetizing. But I would like to at least know if you hate the "extended
>> scratch" (ignore the name) as a concept or only the code it results in.
>
> Let's retry this one :)
>
> I looked more closely, and it seems that mixing SCRATCH and SCRATCH_EXT
> should be a lesser headache than going with option 4.

I also had some time to ruminate on this. I still think option 1 has the
most promise, but my opinion on option 4 has improved a bit. While I
still am not sure adding a 3rd phase to struct page/MM init (early ->
deferred -> KHO reserved blocks) is a good idea, I think it might not be
as bad as I first thought. Dunno...

Anyway, for now I think I will try to make option 1 more appetizing.

Here's an idea I want to try out: I get rid of SCRATCH_EXT and mark the
free blocks as SCRATCH. For HugeTLB, I can teach the special
memblock_alloc_hugetlb_something() function to exclude scratch areas
when looking for free memory ranges. So core memblock does not get a new
memory type, and the complexity of hugepage allocation does not leak
into memblock.

How does that sound?

>
> Tracking the changes in gigantic pages in hugetlb also does not seem
> something we'd like to pursue especially considering that memory from freed
> or demoted gigantic pages could be reserved.
>
> If we add a dedicated memblock_something to allocate gigantic pages, we
> can reduce branching in alloc_bootmem() to
>
> 	if (cma)
> 		do_cma()
> 	else
> 		do_memblock()
>
> For hugetlb_cma we might want to teach CMA to create pre-allocated areas
> and then it could reuse the same memblock API. This seems useful even
> regardless of KHO.

Sorry, I don't get what you mean by this. What pre-allocated areas? When
creating CMA areas it calls cma_alloc_mem() which calls into memblock.
What would we change about this?

-- 
Regards,
Pratyush Yadav