Re: [PATCH 0/4] kho: rename "scratch" to "bootmem"

On Mon, Aug 17 2026, Rob Herring wrote:

> On Mon, Aug 17, 2026 at 10:42:00AM -0400, Gregory Price wrote:
>> On Tue, Aug 11, 2026 at 06:26:36PM +0200, Pratyush Yadav wrote:
>> > From: "Pratyush Yadav (Google)" <[email protected]>
>> > 
>> > The term "KHO scratch" is vague and overloaded. It does not accurately
>> > describe what the memory is for. This was discussed previously at [0].
>> > The conclusion was to rename "KHO scratch" to "KHO bootmem", since this
>> > is memory passed by the previous kernel for early boot allocations.
>> > 
>> 
>> This seems like a lot of churn to just rename some stuff, especially for
>> a term "scratch" which is very much understood to mean "temporary
>> working memory region" in common computing parlance.

Gregory,

Maybe. The people who work with the code on a daily basis (me, Mike,
Pasha) think the rename is worthwhile because it helps us grok the code
better.

I think patch 1 and 2 should go in for sure. They make a noticeable
improvement to memblock's code. Without that, memblock might have some
memory marked as MEMBLOCK_KHO_SCRATCH that is part of "scratch" we got
from KHO, and then some other memory also marked as MEMBLOCK_KHO_SCRATCH
that we discovered at boot. Then later, the "scratch from KHO" needs to
be initialized in a different way from "scratch discovered at boot". The
rename to NOPRSRV makes it way more clear what the properties of the
memory are and how memblock should use it.

For patch 3, I am honestly surprised at how large it ended up being. But
I am in principle opposed to the idea that we should not do any
housekeeping because it might cause "churn". So I think if the end
result is better then churn shouldn't stop us.

Of course patch 3 has a lot of potential for bikeshedding so we can
argue all day on what is better.

>> 
>> The boot param name change would also cause breakage for existing
>> systems that update and depend on the scratch parameter.
>> 
>> Is there a non-verbiage reason to justify these changes?  Living with
>> "scratch" seems better than potentially breaking folks.

I renamed the commandline option because similar things have been done
in the past for other options too.

See commit c5bfece2d612 ("nohz: Switch from "extended nohz" to "full
nohz" based naming") for example. It renamed "nohz_extended" to
"nohz_full" because it is "a bit opaque and vague".

Or commit 9406415f46f6 ("sched/debug: Rename the sched_debug parameter
to sched_verbose"). Or a94e88cdd805 ("ACPICA: Tables: Avoid SSDT
installation with acpi_gbl_disable_ssdt_table_load."). Or 632ff6170647
("x86/microcode: Add microcode= cmdline parsing"). There are a handful
more.

So I think there is a bit of history of command line options being
renamed to names the developers think are better.

Also, I would imagine very few people are using kho_scratch= blindly.
Since kho=on already does a pretty good job of automatically selecting
the sizes, most people should not be using this option at all. Manual
sizing of scratch areas is tricky and should only be done very carefully
by observing each system's characteristics. And the numbers should be
re-calibrated on each kernel upgrade since a new kernel might use more
(or less) memory at boot. So really, I think the change is a lot less
disruptive than you think.

That said, I am not opposed to keeping backwards compatibility if
someone _does_ complain.

> I don't think these are the first breaking changes. And if the changes 

Rob,

What do you mean? None of the KHO's commandline options have changed
before. And KHO has no uAPI to break in the first place.

> are fine, then that means more breaking changes are fine, too. So why is 
> this upstream at all until the design is settled?
>
> Rob

-- 
Regards,
Pratyush Yadav