From: Pratyush Yadav <pratyush@kernel.org>
To: "Mike Rapoport (Microsoft)" <rppt@kernel.org>
Cc: Pasha Tatashin <pasha.tatashin@soleen.com>,
Pratyush Yadav <pratyush@kernel.org>,
Alexander Graf <graf@amazon.com>,
Andrew Morton <akpm@linux-foundation.org>,
Chen Pei <cp0613@linux.alibaba.com>,
George Guo <guodongtai@kylinos.cn>,
Kexin Liu <liukexin@kylinos.cn>,
Sourabh Jain <sourabhjain@linux.ibm.com>,
kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org
Subject: Re: [PATCH v2 3/3] kho: fix bootmem sizing
Date: Tue, 10 Nov 2026 17:54:06 +0100 [thread overview]
Message-ID: <2vxz33t8iq4x.fsf@kernel.org> (raw)
In-Reply-To: <20261104-kho-bootmem-sizing-v2-3-b0d1a834780f@kernel.org> (Mike Rapoport's message of "Wed, 04 Nov 2026 18:50:11 +0200")
On Wed, Nov 04 2026, Mike Rapoport (Microsoft) wrote:
> Bootmem areas are sized from overlapping views of the memory reserved in
> memblock:
>
> * the global area is sized from all reserved memory, including memory
> allocated on specific nodes, so on NUMA systems everything allocated
> on a node is accounted in both the global area and the area of that
> node.
> * per-node sizes are calculated after the lowmem and the global areas
> are reserved. With CONFIG_NUMA=n all memblock regions belong to node 0,
> so the lowmem and the global areas are accounted in the size of node 0
> area and scaled once again.
>
> As a result, bootmem is about twice bigger than it should be on NUMA
> systems and about four times bigger with CONFIG_NUMA=n. On small systems
> reservation of the bootmem may fail and then KHO gets disabled.
>
> Make the areas cover separate parts of the reserved memory: the lowmem
> area covers allocations below ARCH_LOW_ADDRESS_LIMIT, per-node areas
> cover allocations above it on each node and the global area covers
> allocations that are not bound to any node. Calculate all sizes before
> reserving any of the areas.
>
> With CONFIG_NUMA=n the global area becomes empty and it is not reserved.
>
> If ARCH_LOW_ADDRESS_LIMIT covers all memory, as may happen on arm64, any
> area can serve lowmem allocations, so don't reserve the lowmem area.
>
> Bootmem sizes in MiB in x86 QEMU VMs, before -> after:
>
> CONFIG_NUMA=y CONFIG_NUMA=n
> 1G, 1 node 176 -> 92 320 -> 80
> 4G, 1 node 508 -> 332 1264 -> 316
> 16G, 2 nodes 1268 -> 704 2944 -> 736
> 32G, 4 nodes 2296 -> 1224 5196 -> 1300
> 64G, 4 nodes 4344 -> 2248 9664 -> 2420
>
> Fixes: 3dc92c311498 ("kexec: add Kexec HandOver (KHO) generation helpers")
> Reported-by: Kexin Liu <liukexin@kylinos.cn>
> Reported-by: George Guo <guodongtai@kylinos.cn>
> Closes: https://lore.kernel.org/all/20260904025101.9959-1-dongtai.guo@linux.dev
> Reported-by: Sourabh Jain <sourabhjain@linux.ibm.com>
> Closes: https://lore.kernel.org/all/20260922131217.698809-1-sourabhjain@linux.ibm.com
> Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Reviewed-by: Pratyush Yadav <pratyush@kernel.org>
[...]
--
Regards,
Pratyush Yadav
next prev parent reply other threads:[~2026-11-10 16:54 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-04 16:50 [PATCH v2 0/3] kho: fix bootmem sizing Mike Rapoport (Microsoft)
2026-11-04 16:50 ` [PATCH v2 1/3] kho: walk bootmem areas in address order Mike Rapoport (Microsoft)
2026-11-04 18:57 ` Pasha Tatashin
2026-11-04 22:14 ` Jose A. Perez de Azpillaga
2026-11-10 16:52 ` Pratyush Yadav
2026-11-12 6:32 ` Mukesh Pilaniya
2026-11-12 8:49 ` Mike Rapoport
2026-11-04 16:50 ` [PATCH v2 2/3] kho: skip zero-sized lowmem and global bootmem areas Mike Rapoport (Microsoft)
2026-11-04 18:57 ` Pasha Tatashin
2026-11-04 22:17 ` Jose A. Perez de Azpillaga
2026-11-10 16:55 ` Pratyush Yadav
2026-11-12 6:48 ` Mukesh Pilaniya
2026-11-04 16:50 ` [PATCH v2 3/3] kho: fix bootmem sizing Mike Rapoport (Microsoft)
2026-11-04 18:57 ` Pasha Tatashin
2026-11-05 9:26 ` Mike Rapoport
2026-11-04 22:17 ` Jose A. Perez de Azpillaga
2026-11-10 16:54 ` Pratyush Yadav [this message]
2026-11-12 7:21 ` Mukesh Pilaniya
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2vxz33t8iq4x.fsf@kernel.org \
--to=pratyush@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=cp0613@linux.alibaba.com \
--cc=graf@amazon.com \
--cc=guodongtai@kylinos.cn \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=liukexin@kylinos.cn \
--cc=pasha.tatashin@soleen.com \
--cc=rppt@kernel.org \
--cc=sourabhjain@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.