Re: [PATCH v2] mm/hugetlb: allow crashkernel to reuse hugetlb CMA memory

[Usama Arif <usama.arif@linux.dev>]

On Tue, 10 Nov 2026 18:39:34 +0800 Jinjie Ruan <ruanjinjie@huawei.com> wrote:

> 
> 
> 在 2026/11/7 0:51, Usama Arif 写道:
> > crashkernel=size,cma reserves a separate CMA pool. On systems that
> > already reserve several gigabytes with hugetlb_cma= (which is common in
> > the Meta fleet), the crash kernel cannot use that existing memory as
> > part of its working set. With hugetlb_cma=6G, requesting another 2G
> > with crashkernel=2G,cma brings the total CMA reservation to 8G, none of
> > which can serve unmovable kernel allocations.
> > 
> > Use existing HugeTLB CMA memory first for crashkernel=size,cma and
> > reserve dedicated CMA areas only for the remainder. With hugetlb_cma=6G,
> > a 2G request reuses 2G without reserving more CMA. With hugetlb_cma=2G,
> > a 4G request reuses 2G and reserves another 2G.
> > 
> > The full HugeTLB CMA pool remains available to HugeTLB and movable
> > allocations during normal operation. After a crash, the capture kernel
> > can use the selected ranges as working memory. The conventional
> > reservation is still required to hold the kernel image and initrd.
> > 
> > The ,cma option already opts into excluding userspace memory from the
> > vmcore. This includes allocated HugeTLB pages in the selected ranges,
> > which the capture kernel can overwrite. The existing dump completeness
> > and pending DMA risks apply to these ranges as well.
> > 
> > Have architecture code record the requested CMA size and perform the
> > reservation in mm_core_init_early(), immediately after
> > hugetlb_cma_reserve(). The HugeTLB CMA areas are then available for reuse
> > while memblock can still reserve any remainder.
> > 
> > Use the existing four range slots for both reused and dedicated memory.
> > Limit reused memory to the page-aligned request, account for dedicated
> > CMA alignment, and report any shortfall. Ignore malformed optional sizes
> > and reject requests that would overflow page rounding.
> > 
> > Suggested-by: Breno Leitao <leitao@debian.org>
> > Signed-off-by: Usama Arif <usama.arif@linux.dev>
> > ---
> > v1 -> v2:
> > - Use existing HugeTLB CMA memory first for crashkernel=size,cma and
> >   reserve dedicated CMA areas only for the remainder. (Kiryl)
> > ---
> >  .../ABI/testing/sysfs-kernel-kexec-kdump      |  3 ++
> >  Documentation/admin-guide/kdump/kdump.rst     | 22 ++++++--
> >  .../admin-guide/kernel-parameters.txt         | 16 +++++-
> >  arch/arm64/mm/init.c                          |  2 +-
> >  arch/powerpc/include/asm/kexec.h              |  2 -
> >  arch/powerpc/kexec/core.c                     | 12 ++---
> >  arch/powerpc/mm/mem.c                         |  6 +--
> >  arch/riscv/mm/init.c                          |  2 +-
> >  arch/x86/kernel/setup.c                       |  2 +-
> >  include/linux/crash_reserve.h                 | 14 ++++-
> >  include/linux/hugetlb.h                       | 12 +++++
> >  kernel/crash_reserve.c                        | 51 ++++++++++++++-----
> >  mm/hugetlb_cma.c                              | 50 ++++++++++++++++++
> >  mm/mm_init.c                                  |  2 +
> >  14 files changed, 159 insertions(+), 37 deletions(-)
> 
> Should it be separated according to the architecture and framework code?
> 

IMO, the commit and change ins small and simple enough that it doesnt need
to be separated into different commits.