Re: [PATCH 09/12] memblock: introduce MEMBLOCK_KHO_SCRATCH_EXT

[Mike Rapoport <rppt@kernel.org>]

On Fri, May 22, 2026 at 05:02:38PM +0200, Pratyush Yadav wrote:
> On Fri, May 22 2026, Pasha Tatashin wrote:
> 
> > On 05-11 18:46, Pratyush Yadav wrote:
> >> On Mon, May 11 2026, Mike Rapoport wrote:
> >> 
> >> > On Wed, Apr 29, 2026 at 03:39:11PM +0200, Pratyush Yadav wrote:
> >> >> From: "Pratyush Yadav (Google)" <pratyush@kernel.org>
> >> >> 
> >> >> In the upcoming commits, the KHO will learn how to discover free blocks
> >> >> of memory by walking the KHO radix tree. It will then mark those regions
> >> >> as scratch to allow memory allocation in case scratch runs low.
> >> >> 
> >> >> To differentiate the extended scratch areas from the main scratch areas,
> >> >> introduce MEMBLOCK_KHO_SCRATCH_EXT. Use it when choosing memblock flags
> >> >> for allocations during scratch-only. Teach should_skip_region() to check
> >> >> for both flags before deciding if the region should be skipped.
> >> >
> >> > Why there's a need to differentiate SCRATCH and SCRATCH_EXT?
> >> > SCRATCH (I still hate the name) means "memory memblock can safely use for
> >
> >  +1000
> >
> > I also strongly dislike this name and mentioned it in another thread
> > earlier today.
> >
> > If we ever decide to s/scratch/something-else/ globally, that should be a
> > separate cleanup effort. However, since we are introducing a brand new flag
> > here, we can discuss a better name for the _ext portion to avoid overloading
> > the "scratch" concept.
> >
> >> > the allocations". Initially this memory comes from the reservations in the
> >> > first kernel, but if the second kernel can find more memory to extend it,
> >> > why that additional memory should be treated differently? 
> >> 
> >> Two reasons:
> >> 
> >> 1. We mark SCRATCH as MIGRATE_CMA. We don't want to do that for
> >>    SCRATCH_EXT since this memory can be used for non-movable
> >>    allocations.
> >> 
> >> 2. Gigantic (1G) huge pages can not be allocated from scratch. They can
> >>    be preserved memory and thus should not be allocated from SCRATCH.
> >>    See patch 12 that does allocations for gigantic huge pages only from
> >>    SCRATCH_EXT.
> >> 
> >> I will add this in the commit message for the next version.
> >> 
> >> Naming is hard, so if you have any better names I'm all ears :-)
> >
> > IMO, this scratch_ext is not "scratch" in the traditional KHO sense at all.
> > The traditional KHO scratch is what is passed from kernel to kernel and is
> > guaranteed to contain zero preserved memory. This new memory is not passed
> > from kernel to kernel and can contain preserved memory at runtime. It's
> > essentially just memory that we identify as currently unpreserved and release
> > early to the system.
> >
> > If we want to keep the naming aligned with the existing codebase for now:
> > MEMBLOCK_KHO_SCRATCH      -> original scratch
> > MEMBLOCK_KHO_UNPRESERVED  -> for the new memory (instead of SCRATCH_EXT)
> 
> UNPRESERVED sounds good to me. I will use that for the next revision
> unless Mike objects.
 
Can we make it shorter? ;-)

UNPRESERVED makes sense, although I'd love to completely remove KHO_ notion
and make the name reflect how it's used by memblock. I was toying with
PREFERRED instead of SCRATCH, but it didn't feel right enough.
With two of them that surely won't work :)

> > Alternatively, if we do want to tackle the global rename of "scratch" later:
> > MEMBLOCK_KHO_BOOTSTRAP    -> for the original scratch
> > MEMBLOCK_KHO_UNPRESERVED  -> for this new dynamic memory
> 
> Or perhaps BOOTMEM? I suppose either of the two are somewhat better than
> scratch.

Well, if we have BOOTMEM_HVO, we can have BOOTMEM_KHO as well :)

> Anyway, can we please do the SCRATCH rename as a separate series? I

Sure. We can continue bikeshedding in parallel.

> would like this series to not get muddled in the naming discussion. I
> will use UNPRESERVED for the new concept in v2 though.

That might warrant v3 even if everything else is perfect :)
 
> -- 
> Regards,
> Pratyush Yadav

-- 
Sincerely yours,
Mike.