On 31/10/25 16:48, Ritesh Harjani (IBM) wrote:
Ritesh Harjani (IBM) <[email protected]> writes:
I am not much familiar with the crash kernel workings but was curious
about the following query related to this patch:
As I understand this patch allows for the remaining crash kernel
memory to come from CMA region. But do we limit the CMA region to be lower
than 4G?
No we are not and we don't need to.
Is this patch dependent over your other patch series [1] which
supports high crashkernel reservation?
[1]:
https://lore.kernel.org/linuxppc-dev/[email protected]/
No, this is an independent patch.
Say, if we are in Hash mode and if the CMA reservations have come from
higher addresses. Will that work with kdump kernel when it boots with Hash
mmu? Because memory region beyond RMA is not accessible in Hash correct?
Oh sorry my bad! I think I got the answer to above question now.
So this feature allows us to reserve the "extra memory" using CMA which
is mainly used to serve the kdump kernel's memory allocation requests.
So we will have two memory reservations i.e.
crashkernel=64M,crashkernel=1G,cma.
So the second 1G cma reservation is mainly to serve the kdump kernel's
memory allocation requests to avoid the ooms. And this will only be
required once the MMU is initialized, so we don't have those RMA
restrictions which are only during early init time (before Hash is
initialized).
Yes, exactly. The regular reservation will be done as usual, and the kdump
image (vmlinux, initrd, dtb, etc.) will be loaded in the regular crashkernel
reserved region. So, no impact is expected due to the MMU type in use.
- Sourabh Jain
