Re: [RFC PATCH 2/3] powerpc: add support for Kexec HandOver (KHO)

On Fri, Sep 04, 2026 at 06:22:18PM +0200, Pratyush Yadav wrote:

On Fri, Sep 04 2026, Sourabh Jain wrote:

quoted

On 02/09/26 16:04, Pratyush Yadav wrote:

quoted

On Sun, Aug 23 2026, Sourabh Jain wrote:

quoted

On 21/08/26 17:26, Pratyush Yadav wrote:

quoted

On Fri, Aug 21 2026, Sourabh Jain wrote:

[...]

quoted

quoted

quoted

I agree that this is one way to work around the low-memory reservation problem.
However, there are a few things that come into play here:

1. On powerpc, the crashkernel reservation can go up to 64 GB for kdump. With
the
    current default scratch memory reservation policy, this could result in
reserving
    up to 256 GB of scratch memory: 200% for the high-memory reservation and
another
    200% for per-node memory.

That calculation looks off. It _should_ be 200% once not twice. So 128
GB total. If the allocation came out via the global area, it should
_only_ be accounted to the global scratch size. Similarly, only the
allocations made specifically on that node should be counted for the
per-node scratch size.

For example, if a system has only one node and 64 GB is allocated from
that node before the kernel starts calculating the per-node and global
allocations for scratch memory, wouldn't the per-node allocation also be 64 GB?

If so, wouldn't that result in 200% of 64 GB being allocated for the global
area and another 200% of 64 GB for the per-node area, resulting in 256 GB
of total scratch memory allocation? Or am I missing something here?

It shouldn't. If the 64 GB of allocation was done with NUMA_NO_NODE, and
it _happened_ to land on node X, it should not be counted for per-node
sizing. It should count towards the global pool. Only allocations that
were explicitly requested with node X should be count for that node's
scratch size.

So on a one node system where 64G of memory is allocated with
NUMA_NO_NODE and 8G is allocated with node X, we should get 128G of
global scratch and 16G of per-node scratch, giving us a total of 144G.

I took a quick look and it looks like the problem might be that the
calculation for global scratch includes _all_ nodes in it. See
memblock_reserved_kern_size():

	for_each_reserved_mem_region(r) {
		...
                
		if (nid == memblock_get_region_node(r) || !numa_valid_node(nid))
			if (r->flags & MEMBLOCK_RSRV_KERN)
				total += size;
	}

And for global scratch we pass nid as NUMA_NO_NODE.

For KHO we could just drop the || !numa_valid_node(), but
memblock_estimated_nr_free_pages() seems to depend on that behaviour. It
wants to get _all_ allocations across all nodes. KHO only wants
allocations explicitly made with NUMA_NO_NODE.

But disclaimer: all this is from reading the code for maybe 15 minutes.
I didn't run anything and might be missing something. So please
double-check what I am saying.

That sounds about right, although I didn't check anything at all :)
 

quoted

BTW, do you know the rationale behind the 200% value?

I couldn't find any explanation for it in the commit message of
3dc92c311498c ("kexec: add Kexec HandOver (KHO) generation helpers")

We need to ask Alex (or maybe Mike?; I forget who added this).

But if I were to guess, I don't think there is much science involved
behind the number. Since the scratch lives across all kexecs, it needs
to be large enough in case the next kernel uses more memory. 200% sounds
"large enough".

Yeah, that was the rationale indeed :)

-- 
Regards,
Pratyush Yadav

-- 
Sincerely yours,
Mike.