On Mon, Oct 13, 2025 at 4:01 PM David Hildenbrand <[email protected]> wrote: > > On 13.10.25 06:03, Zhongkun He wrote: > > Hi folks, > > > > We’re encountering the same issue that this patch series aims to address, > > and we also planned to leverage CMA to solve it. However, some > > implementation > > details on our side may differ, so we’d like to discuss our proposed > > approach we > > have tried in this thread. > > > > 1. Register a dedicated CMA area for kexec kernel use > > Introduce a dedicated CMA region (e.g., kexec_cma) and allocate the control > > code page and crash segments from this area via cma_alloc. Pages for a > > normal kexec kernel can also be allocated from this region [1]. > > > > 2. Keep crashkernel=xx unchanged (register CMA) > > We introduced a flag in the kexec syscall to dynamically enable > > or disable memory reuse without system reboot. For example, with > > crashkernel=500M (a 500M cma region), cma_alloc may use 100M for the > > kernel,initrd and others data. This region could then be reused for the > > current > > kernel if the reuse flag is set in the syscall, or left unused for dumping > > user > > pages in case of a crash. > > > > 3. Keep this CMA region inactive by default > > The CMA region should remain inactive until kexec is enabled with the reuse > > flag > > (or fully reused when the kdump service is not enabled). It can then > > be activated for > > use by the current kernel. > > > > 4. Introduce a new migratetype KEXEC_CMA > > Similar to the existing CMA type, this would be used to: > > 1)Prevent page allocation from this zone for get_user_pages (GUP). > > 2)Handle page migration correctly when pages are pinned after allocation. >
Hi David, > It will be hard to get something like that in for the purpose of kdump. > Further, I'm afraid it might open up a can of worms of "migration > temporarily failed" -> GUP failed issues for some workloads. > > So I assume this might currently not be the best way to move forward. Got it, thanks. > > One alternative would be using GCMA [1] in the current design. The CMA > memory would not be exposed to the buddy, but can still be used as a > cache for clean file pages. Pinning etc. is not a problem in that context. > > Of course, the more we limit the usage of that region, the less > versatile it is. Yes, I agree. I’ve already noticed GCMA, and I hope it can be merged upstream in a more lightweight manner. > > [1] https://lkml.kernel.org/r/[email protected] > > -- > Cheers > > David / dhildenb >
