Re: [PATCH] kho: fix global scratch size calculation

[Mike Rapoport <rppt@kernel.org>]

On Mon, Oct 12, 2026 at 03:52:46PM +0200, Pratyush Yadav wrote:
> On Sat, Oct 03 2026, Mike Rapoport wrote:
> 
> > On Tue, Sep 22, 2026 at 06:42:16PM +0530, Sourabh Jain wrote:
> >> KHO calculates the global scratch size based on memblock-reserved kernel
> >> memory. It passes NUMA_NO_NODE to memblock_reserved_kern_size() for
> >> this calculation.
> >> 
> >> When memblock_reserved_kern_size() is called with NUMA_NO_NODE, it
> >> counts both:
> >> 
> >> - memory reserved for a specific NUMA node
> >> - memory reserved with NUMA_NO_NODE
> >> 
> >> KHO needs to distinguish between these two types of reservations.
> >> When calculating the size of global scratch memory, KHO only needs to
> >> account for reservations made with NUMA_NO_NODE. Reservations made for
> >> a specific NUMA node must not be included in the global scratch size.
> >> 
> >> Add memblock_reserved_size_nid() to calculate reserved memory for a
> >> given reservation type and NUMA node. When NUMA_NO_NODE is passed, it
> >> counts only memory reserved with NUMA_NO_NODE.
> >> 
> >> Use the new API for lowmem, global, and per-node KHO scratch size
> >> calculations. For lowmem and global scratch, count only memory
> >> reservations that were made with NUMA_NO_NODE. For per-node scratch,
> >> count only memory reservations that were made with the corresponding
> >> NUMA node ID.
> >> 
> >> Remove memblock_reserved_hugetlb_size() since it has the same
> >> implementation as the new API and differs only in the memblock
> >> reservation flag being checked. The new API handles both kernel and
> >> HugeTLB reservations through its reservation type argument.
> >> 
> >> Define the new helper as a static function in the KHO implementation,
> >> since it is only used by KHO and has no users outside
> >> kernel/liveupdate/kexec_handover.c.
> >
> > I looked again and this feels like a band-aid to me.
> >
> > I think we need to step back and rethink the order of the
> > scratch/kho-bootmem sizing and consider how NUMA and lowmem are involved
> > there.
> 
> Could you elaborate? How else would you calculate the sizes?
> 
> To me, the idea sounds fine (although I also share your comments on the
> code style). This is what the global scratch size should have been doing
> from the get-go. Today it over-allocates by counting both global
> allocations and _all_ per-node allocations.
 
> There is a separate problem with CONFIG_NUMA=n, but for that I think we
> should just have a different allocation path where we only do lowmem and
> global scratch.

I mean more fundamental code refactoring that takes into the account all
cases (and I could miss some)

- NUMA vs no-NUMA
- systems that have global scratch containing lowmem scratch vs those that
  don't
- and of course fix global scratch over-allocation
 
> >> On powerpc, the difference can be seen in the scratch_len values
> >> reported by:
> >> 
> >> cat /sys/kernel/debug/kho/out/scratch_len
> >> 
> >> Before this change, the global scratch allocation was 0x12000000
> >> (288 MB):
> >> 
> >> 0x1000000   (16 MB)
> >> 0x12000000  (288 MB)  <- global allocation
> >> 0x5000000   (80 MB)
> >> 
> >> After this change, the global scratch allocation is 0xd000000
> >> (208 MB):
> >> 
> >> 0x1000000   (16 MB)
> >> 0xd000000   (208 MB)  <- global allocation
> >> 0x5000000   (80 MB)
> >> 
> >> The 80 MB difference is the per-node reservation that was previously
> >> being included in the global allocation.
> >> 
> >> The same issue also affects lowmem scratch memory, but its impact is
> >> limited because the lowmem scratch memory calculation is restricted to
> >> the first 4G of memory. The changes also cover the lowmem scratch
> >> memory case.
> >> 
> >> Cc: Alexander Graf <graf@amazon.com>
> >> Cc: Andrew Morton <akpm@linux-foundation.org>
> >> Cc: George Guo <guodongtai@kylinos.cn>
> >> Cc: Mike Rapoport <rppt@kernel.org>
> >> Cc: Pasha Tatashin <pasha.tatashin@soleen.com>
> >> Cc: Pratyush Yadav <pratyush@kernel.org>
> >> Cc: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
> >> Cc: linux-kernel@vger.kernel.org
> >> Cc: linux-mm@kvack.org
> >> Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
> [...]
> 
> -- 
> Regards,
> Pratyush Yadav

-- 
Sincerely yours,
Mike.