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

[Mike Rapoport]

On Tue, Jun 02, 2026 at 03:35:44PM +0200, Pratyush Yadav wrote:
> 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 at 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...

Until (if ever) we enlighten memblock_free_all()/deferred_init_pages()
about KHO, small scattered reservation make memblock slower. It's hard to
tell if delaying more complex initialization of the large reserved chunks
until SMP is worth speedup in a few memblock operations between
kho_memory_init() and the end of deferred_init_pages().
 
> 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?

It sounds fine, let's see how it looks :) 

> > 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?

s/teach CMA to create/teach CMA to use/

I mean that we might want to be able first allocate gigantic pages and then
feed them to empty CMA areas.
 
> -- 
> Regards,
> Pratyush Yadav

-- 
Sincerely yours,
Mike.