[PATCH] kho: fix global scratch size calculation

[Pratyush Yadav]

On Mon, Oct 12 2026, Mike Rapoport wrote:

> 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

Fair enough, that makes sense.

[...]

-- 
Regards,
Pratyush Yadav