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

[Pratyush Yadav <pratyush@kernel.org>]

On Sun, May 31 2026, Mike Rapoport wrote:

> 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 :)

I don't think you really can remove KHO_ notion. These memory regions
only make sense on a KHO boot, and won't exist otherwise. And PREFERRED
sounds like a suggestion/priority hint, not a hard limit. "With KHO
boot, you can _only_ use PREFERRED memory", doesn't sound right...

I think MEMBLOCK_KHO_BOOTMEM for scratch and MEMBLOCK_KHO_NOPRESERVE
(which I think is a tiny bit better than UNPRESERVED) for scratch_ext
are my top picks. To make it shorter, perhaps MEMBLOCK_KHO_NOPRSRV, in
similar fashion to RSRV_KERN?

>
>> > 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 :)

I can live with that. As long as we can agree on the easy part (the
code), I don't mind doing another version for the hard part (the naming)
;-)

-- 
Regards,
Pratyush Yadav