Describe the new crashkernel ",cma" suffix in Documentation/
Signed-off-by: Jiri Bohac <jbohac@suse.cz>
---
Documentation/admin-guide/kdump/kdump.rst | 24 +++++++++++++++++--
.../admin-guide/kernel-parameters.txt | 22 +++++++++++++++++
2 files changed, 44 insertions(+), 2 deletions(-)
diff --git a/Documentation/admin-guide/kdump/kdump.rst b/Documentation/admin-guide/kdump/kdump.rst
index 5376890adbeb..0a7ec98c74fa 100644
--- a/Documentation/admin-guide/kdump/kdump.rst
+++ b/Documentation/admin-guide/kdump/kdump.rst
@@ -315,6 +314,27 @@ crashkernel syntax
crashkernel=0,low
+4) crashkernel=size,cma
+
+ Reserve additional crash kernel memory from CMA. This reservation is
+ usable by the first system's userspace memory and kernel movable
+ allocations (memory balloon, zswap). Pages allocated from this memory
+ range will not be included in the vmcore so this should not be used if
+ dumping of userspace memory is intended and it has to be expected that
+ some movable kernel pages may be missing from the dump.
+
+ A standard crashkernel reservation, as described above, is still needed
+ to hold the crash kernel and initrd.
+
+ This option increases the risk of a kdump failure: DMA transfers
+ configured by the first kernel may end up corrupting the second
+ kernel's memory.
+
+ This reservation method is intended for systems that can't afford to
+ sacrifice enough memory for standard crashkernel reservation and where
+ less reliable and possibly incomplete kdump is preferable to no kdump at
+ all.
+
Boot into System Kernel
-----------------------
1) Update the boot loader (such as grub, yaboot, or lilo) configuration
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index fb8752b42ec8..895b974dc3bb 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -987,6 +987,28 @@
0: to disable low allocation.
It will be ignored when crashkernel=X,high is not used
or memory reserved is below 4G.
+ crashkernel=size[KMG],cma
+ [KNL, X86] Reserve additional crash kernel memory from
+ CMA. This reservation is usable by the first system's
+ userspace memory and kernel movable allocations (memory
+ balloon, zswap). Pages allocated from this memory range
+ will not be included in the vmcore so this should not
+ be used if dumping of userspace memory is intended and
+ it has to be expected that some movable kernel pages
+ may be missing from the dump.
+
+ A standard crashkernel reservation, as described above,
+ is still needed to hold the crash kernel and initrd.
+
+ This option increases the risk of a kdump failure: DMA
+ transfers configured by the first kernel may end up
+ corrupting the second kernel's memory.
+
+ This reservation method is intended for systems that
+ can't afford to sacrifice enough memory for standard
+ crashkernel reservation and where less reliable and
+ possibly incomplete kdump is preferable to no kdump at
+ all.
cryptomgr.notests
[KNL] Disable crypto self-tests
--
Jiri Bohac <jbohac@suse.cz>
SUSE Labs, Prague, CzechiaHi Jiri, On 03/12/25 at 10:09pm, Jiri Bohac wrote: ...... > diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt > index fb8752b42ec8..895b974dc3bb 100644 > --- a/Documentation/admin-guide/kernel-parameters.txt > +++ b/Documentation/admin-guide/kernel-parameters.txt > @@ -987,6 +987,28 @@ > 0: to disable low allocation. > It will be ignored when crashkernel=X,high is not used > or memory reserved is below 4G. > + crashkernel=size[KMG],cma > + [KNL, X86] Reserve additional crash kernel memory from > + CMA. This reservation is usable by the first system's > + userspace memory and kernel movable allocations (memory > + balloon, zswap). Pages allocated from this memory range > + will not be included in the vmcore so this should not > + be used if dumping of userspace memory is intended and > + it has to be expected that some movable kernel pages > + may be missing from the dump. Since David and Don expressed concern about the missing kernel pages allocated from CMA area in v2, and you argued this is still useful for VM system, I would like to invite David to help evaluate the whole series if it's worth from the VM and MM point of view. Thanks Baoquan > + > + A standard crashkernel reservation, as described above, > + is still needed to hold the crash kernel and initrd. > + > + This option increases the risk of a kdump failure: DMA > + transfers configured by the first kernel may end up > + corrupting the second kernel's memory. > + > + This reservation method is intended for systems that > + can't afford to sacrifice enough memory for standard > + crashkernel reservation and where less reliable and > + possibly incomplete kdump is preferable to no kdump at > + all. > > cryptomgr.notests > [KNL] Disable crypto self-tests > > -- > Jiri Bohac <jbohac@suse.cz> > SUSE Labs, Prague, Czechia >
On 14.03.25 04:18, Baoquan He wrote: > Hi Jiri, > > On 03/12/25 at 10:09pm, Jiri Bohac wrote: > ...... >> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt >> index fb8752b42ec8..895b974dc3bb 100644 >> --- a/Documentation/admin-guide/kernel-parameters.txt >> +++ b/Documentation/admin-guide/kernel-parameters.txt >> @@ -987,6 +987,28 @@ >> 0: to disable low allocation. >> It will be ignored when crashkernel=X,high is not used >> or memory reserved is below 4G. >> + crashkernel=size[KMG],cma >> + [KNL, X86] Reserve additional crash kernel memory from >> + CMA. This reservation is usable by the first system's >> + userspace memory and kernel movable allocations (memory >> + balloon, zswap). Pages allocated from this memory range >> + will not be included in the vmcore so this should not >> + be used if dumping of userspace memory is intended and >> + it has to be expected that some movable kernel pages >> + may be missing from the dump. > > Since David and Don expressed concern about the missing kernel pages > allocated from CMA area in v2, and you argued this is still useful for > VM system, I would like to invite David to help evaluate the whole > series if it's worth from the VM and MM point of view. Balloon pages will not be dumped either way (PageOffline), so that is not a convern. Zsmalloc pages ... are probably fine right now. They should likely only be storing compressed user data. (not sure if they also store some other datastructures, I think no, but might be wrong) My comment was rather forward-looking: that CMA memory only contains user space memory is already not the case (but the existing cases might be okay). In the future, as we support other movable allocations (as raised, leaf page tables at some point, and there were discussions about movable slab pages, although that might be challenging) this can change (unless we find ways of not placing these allocations on CMA memory). So as is, this should be fine, but it's certainly something to be aware of in the future. -- Cheers, David / dhildenb
On 27.06.25 14:16, David Hildenbrand wrote: > On 14.03.25 04:18, Baoquan He wrote: >> Hi Jiri, >> >> On 03/12/25 at 10:09pm, Jiri Bohac wrote: >> ...... >>> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt >>> index fb8752b42ec8..895b974dc3bb 100644 >>> --- a/Documentation/admin-guide/kernel-parameters.txt >>> +++ b/Documentation/admin-guide/kernel-parameters.txt >>> @@ -987,6 +987,28 @@ >>> 0: to disable low allocation. >>> It will be ignored when crashkernel=X,high is not used >>> or memory reserved is below 4G. >>> + crashkernel=size[KMG],cma >>> + [KNL, X86] Reserve additional crash kernel memory from >>> + CMA. This reservation is usable by the first system's >>> + userspace memory and kernel movable allocations (memory >>> + balloon, zswap). Pages allocated from this memory range >>> + will not be included in the vmcore so this should not >>> + be used if dumping of userspace memory is intended and >>> + it has to be expected that some movable kernel pages >>> + may be missing from the dump. >> >> Since David and Don expressed concern about the missing kernel pages >> allocated from CMA area in v2, and you argued this is still useful for >> VM system, I would like to invite David to help evaluate the whole >> series if it's worth from the VM and MM point of view. > > Balloon pages will not be dumped either way (PageOffline), so that is > not a convern. > > Zsmalloc pages ... are probably fine right now. They should likely only > be storing compressed user data. (not sure if they also store some other > datastructures, I think no, but might be wrong) > > My comment was rather forward-looking: that CMA memory only contains > user space memory is already not the case (but the existing cases might > be okay). In the future, as we support other movable allocations (as > raised, leaf page tables at some point, and there were discussions about > movable slab pages, although that might be challenging) this can change > (unless we find ways of not placing these allocations on CMA memory). > > So as is, this should be fine, but it's certainly something to be aware > of in the future. > BTW, I realize this was a late reply, and that the series already proceeded. Just stumbled over that un-replied mail an thought I'd clarify my point here. -- Cheers, David / dhildenb
On 06/27/25 at 02:18pm, David Hildenbrand wrote: > On 27.06.25 14:16, David Hildenbrand wrote: > > On 14.03.25 04:18, Baoquan He wrote: > > > Hi Jiri, > > > > > > On 03/12/25 at 10:09pm, Jiri Bohac wrote: > > > ...... > > > > diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt > > > > index fb8752b42ec8..895b974dc3bb 100644 > > > > --- a/Documentation/admin-guide/kernel-parameters.txt > > > > +++ b/Documentation/admin-guide/kernel-parameters.txt > > > > @@ -987,6 +987,28 @@ > > > > 0: to disable low allocation. > > > > It will be ignored when crashkernel=X,high is not used > > > > or memory reserved is below 4G. > > > > + crashkernel=size[KMG],cma > > > > + [KNL, X86] Reserve additional crash kernel memory from > > > > + CMA. This reservation is usable by the first system's > > > > + userspace memory and kernel movable allocations (memory > > > > + balloon, zswap). Pages allocated from this memory range > > > > + will not be included in the vmcore so this should not > > > > + be used if dumping of userspace memory is intended and > > > > + it has to be expected that some movable kernel pages > > > > + may be missing from the dump. > > > > > > Since David and Don expressed concern about the missing kernel pages > > > allocated from CMA area in v2, and you argued this is still useful for > > > VM system, I would like to invite David to help evaluate the whole > > > series if it's worth from the VM and MM point of view. > > > > Balloon pages will not be dumped either way (PageOffline), so that is > > not a convern. > > > > Zsmalloc pages ... are probably fine right now. They should likely only > > be storing compressed user data. (not sure if they also store some other > > datastructures, I think no, but might be wrong) > > > > My comment was rather forward-looking: that CMA memory only contains > > user space memory is already not the case (but the existing cases might > > be okay). In the future, as we support other movable allocations (as > > raised, leaf page tables at some point, and there were discussions about > > movable slab pages, although that might be challenging) this can change > > (unless we find ways of not placing these allocations on CMA memory). > > > > So as is, this should be fine, but it's certainly something to be aware > > of in the future. > > > > BTW, I realize this was a late reply, and that the series already proceeded. > Just stumbled over that un-replied mail an thought I'd clarify my point > here. Thanks a lot for deliberating on this and providing these helpful details. As you said, this feature is fine for the time being, we can remember this and consider how to adapt in the future once those movable allocations could happen in CMA. And the risk has been told clearly in doc.
© 2016 - 2025 Red Hat, Inc.