[PATCH 09/12] memblock: introduce MEMBLOCK_KHO_SCRATCH_EXT

[Pratyush Yadav]

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 at 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.

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

Anyway, can we please do the SCRATCH rename as a separate series? I
would like this series to not get muddled in the naming discussion. I
will use UNPRESERVED for the new concept in v2 though.

>
> What do you think?
>
> Pasha

-- 
Regards,
Pratyush Yadav