On Fri, Sep 04, 2026 at 06:22:18PM +0200, Pratyush Yadav wrote:
> On Fri, Sep 04 2026, Sourabh Jain wrote:
> > On 02/09/26 16:04, Pratyush Yadav wrote:
> >> On Sun, Aug 23 2026, Sourabh Jain wrote:
> >>
> >>> On 21/08/26 17:26, Pratyush Yadav wrote:
> >>>> On Fri, Aug 21 2026, Sourabh Jain wrote:
> [...]
> >>> 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 :)
> > 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.
