From: Kiryl Shutsemau <kas@kernel.org>
To: Usama Arif <usama.arif@linux.dev>
Cc: Andrew Morton <akpm@linux-foundation.org>,
baoquan.he@linux.dev, rppt@kernel.org,
pasha.tatashin@soleen.com, pratyush@kernel.org,
ruirui.yang@linux.dev, corbet@lwn.net,
skhan@linuxfoundation.org, rdunlap@infradead.org,
muchun.song@linux.dev, osalvador@suse.de, david@kernel.org,
jbohac@suse.cz, sourabhjain@linux.ibm.com,
ruanjinjie@huawei.com, leitao@debian.org,
linux-kernel@vger.kernel.org, kexec@lists.infradead.org,
linux-doc@vger.kernel.org, linux-mm@kvack.org,
hannes@cmpxchg.org, riel@surriel.com, shakeel.butt@linux.dev,
zaslonko@linux.ibm.com, brads@mainlining.org,
kernel-team@meta.com
Subject: Re: [PATCH v2] mm/hugetlb: allow crashkernel to reuse hugetlb CMA memory
Date: Tue, 10 Nov 2026 10:31:05 +0000 [thread overview]
Message-ID: <avLyOzQMBnHYLEst@thinkstation> (raw)
In-Reply-To: <20261106165142.2847916-1-usama.arif@linux.dev>
On Fri, Nov 06, 2026 at 08:51:42AM -0800, Usama Arif wrote:
> 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)
Suggested-by: Kiryl Shutsemau (Meta) <kas@kernel.org>
Acked-by: Kiryl Shutsemau (Meta) <kas@kernel.org>
--
Kiryl Shutsemau / Kirill A. Shutemov
next prev parent reply other threads:[~2026-11-10 10:31 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-06 16:51 [PATCH v2] mm/hugetlb: allow crashkernel to reuse hugetlb CMA memory Usama Arif
2026-11-09 20:07 ` sashiko-bot
2026-11-10 10:31 ` Kiryl Shutsemau [this message]
2026-11-10 10:39 ` Jinjie Ruan
2026-11-10 15:27 ` Usama Arif
2026-11-10 16:02 ` Bradley Morgan
2026-11-10 22:29 ` Mike Rapoport
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=avLyOzQMBnHYLEst@thinkstation \
--to=kas@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=baoquan.he@linux.dev \
--cc=brads@mainlining.org \
--cc=corbet@lwn.net \
--cc=david@kernel.org \
--cc=hannes@cmpxchg.org \
--cc=jbohac@suse.cz \
--cc=kernel-team@meta.com \
--cc=kexec@lists.infradead.org \
--cc=leitao@debian.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=muchun.song@linux.dev \
--cc=osalvador@suse.de \
--cc=pasha.tatashin@soleen.com \
--cc=pratyush@kernel.org \
--cc=rdunlap@infradead.org \
--cc=riel@surriel.com \
--cc=rppt@kernel.org \
--cc=ruanjinjie@huawei.com \
--cc=ruirui.yang@linux.dev \
--cc=shakeel.butt@linux.dev \
--cc=skhan@linuxfoundation.org \
--cc=sourabhjain@linux.ibm.com \
--cc=usama.arif@linux.dev \
--cc=zaslonko@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.