From: Pasha Tatashin <pasha.tatashin@soleen.com>
To: Pratyush Yadav <pratyush@kernel.org>
Cc: Mike Rapoport <rppt@kernel.org>,
Pasha Tatashin <pasha.tatashin@soleen.com>,
Alexander Graf <graf@amazon.com>,
kexec@lists.infradead.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] kho: always print scratch sizes
Date: Thu, 21 May 2026 19:07:47 +0000 [thread overview]
Message-ID: <ag9VrVW3E28UOsAt@plex> (raw)
In-Reply-To: <20260519155324.2692594-1-pratyush@kernel.org>
On 05-19 17:53, Pratyush Yadav wrote:
> From: "Pratyush Yadav (Google)" <pratyush@kernel.org>
>
> Currently, KHO only prints scratch sizes when the size is specified
> by the command line. It prints nothing when the size is calculated
> at runtime by counting RSRV_KERN.
>
> These prints are completely useless. When the user specified the size on
> the command line, they already know how large the scratch areas are. And
> that information is readily available by looking at the command line. It
> is a lot more useful to know the sizes that are calculated at runtime
> since they can vary by kernel version. Plus, if KHO fails to allocate
> the scratch areas, the calculated scratch sizes are not available via
> debugfs.
>
> Print the scratch sizes in kho_reserve_scratch(). Do it before making
> the allocations. The size can provide hints for the failure reason.
>
> Signed-off-by: Pratyush Yadav (Google) <pratyush@kernel.org>
> ---
> kernel/liveupdate/kexec_handover.c | 12 +++++++-----
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/kernel/liveupdate/kexec_handover.c b/kernel/liveupdate/kexec_handover.c
> index 33fcf848ef95..b030f53f2235 100644
> --- a/kernel/liveupdate/kexec_handover.c
> +++ b/kernel/liveupdate/kexec_handover.c
> @@ -621,11 +621,6 @@ static int __init kho_parse_scratch_size(char *p)
> scratch_size_pernode = sizes[2];
> scratch_scale = 0;
>
> - pr_notice("scratch areas: lowmem: %lluMiB global: %lluMiB pernode: %lldMiB\n",
> - (u64)(scratch_size_lowmem >> 20),
> - (u64)(scratch_size_global >> 20),
> - (u64)(scratch_size_pernode >> 20));
> -
> return 0;
> }
> early_param("kho_scratch", kho_parse_scratch_size);
> @@ -691,6 +686,10 @@ static void __init kho_reserve_scratch(void)
> goto err_disable_kho;
> }
>
> + pr_notice("scratch areas: lowmem: %lluMiB global: %lluMiB\n",
> + (u64)(scratch_size_lowmem >> 20),
> + (u64)(scratch_size_global >> 20));
> +
> /*
> * reserve scratch area in low memory for lowmem allocations in the
> * next kernel
> @@ -725,6 +724,9 @@ static void __init kho_reserve_scratch(void)
> */
> for_each_node_state(nid, N_MEMORY) {
> size = scratch_size_node(nid);
> +
> + pr_notice("scratch_areas: nid %d: %lluMiB\n", nid, size >> 20);
Please use a space instead of an underscore to match the other string:
"scratch areas". Keeping the prefix identical makes log parsing and
filtering much cleaner.
Unrelated to this patch—this is something I brought up to Pratyush off-list,
but I really dislike the 'KHO scratch' terminology.
First, it isn't actually 'scratch' space, as the kernel relies on it to
allocate crucial early boot memory, which it then uses permanently.
Second, we cannot preserve anything within this specific region.
Down the line, I'd like to rename this to something more descriptive that clearly
conveys both its importance to early boot and its non-preservable nature. For
now, the print adjustments themselves look good.
I do not know it should be, but something like kho_bootstrap area sounds
better than kho_sratch area.
> +
> addr = memblock_alloc_range_nid(size, CMA_MIN_ALIGNMENT_BYTES,
> 0, MEMBLOCK_ALLOC_ACCESSIBLE,
> nid, true);
>
> base-commit: 34e8f02817e31826e76bb2ded48bf28fe921f20b
> --
> 2.54.0.563.g4f69b47b94-goog
>
prev parent reply other threads:[~2026-05-21 19:07 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-19 15:53 [PATCH] kho: always print scratch sizes Pratyush Yadav
2026-05-21 19:07 ` Pasha Tatashin [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ag9VrVW3E28UOsAt@plex \
--to=pasha.tatashin@soleen.com \
--cc=graf@amazon.com \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=pratyush@kernel.org \
--cc=rppt@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox