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

[Pratyush Yadav]

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.

>  
>> 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@xxxxxxxxxx>
>> Cc: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
>> Cc: George Guo <guodongtai@xxxxxxxxxx>
>> Cc: Mike Rapoport <rppt@xxxxxxxxxx>
>> Cc: Pasha Tatashin <pasha.tatashin@xxxxxxxxxx>
>> Cc: Pratyush Yadav <pratyush@xxxxxxxxxx>
>> Cc: Ritesh Harjani (IBM) <ritesh.list@xxxxxxxxx>
>> Cc: linux-kernel@xxxxxxxxxxxxxxx
>> Cc: linux-mm@xxxxxxxxx
>> Signed-off-by: Sourabh Jain <sourabhjain@xxxxxxxxxxxxx>
[...]

-- 
Regards,
Pratyush Yadav