3:25 p.m.
Add docs about the new reboot estimation.
Signed-off-by: Kairui Song <kasong(a)redhat.com>
---
crashkernel-howto.txt | 104 +++++++++++++++++++++++++++++++++---------
1 file changed, 82 insertions(+), 22 deletions(-)
diff --git a/crashkernel-howto.txt b/crashkernel-howto.txt
index 20f50e03..4f03c225 100644
--- a/crashkernel-howto.txt
+++ b/crashkernel-howto.txt
@@ -171,34 +171,94 @@ kernels to current boot kernel's crashkernel.default` is:
Estimate crashkernel
====================
+Estimate manually
+-----------------
+
The best way to estimate a usable crashkernel value is by testing kdump
-manually. And you can set crashkernel to a large value, then adjust the
-crashkernel value to an acceptable value gradually.
+manually. You can set crashkernel to a large value, then adjust the crashkernel
+value gradually to an acceptable value.
+
+You can use /usr/lib/modules/$(uname -r)/crashkernel.default as a reference and
+adjust the crashkernel value based on that.
+
+Some components will consume a significantly large amount of memory for kdump,
+eg. AMD SME, LUKS2 with argon2. You may need to increase kdump memory to an
+obvious large value in such a case, and unfortunately, there is no good solution
+yet.
-`kdumpctl` also provides a sub-command for doing rough estimating without
-triggering kdump:
+kdumpctl assisted estimation
+----------------------------
+
+`kdumpctl` also provides a sub-command for helping you to estimate the kdump
+crashkernel usage:
`kdumpctl estimate`
-The output will be like this:
+By running this `kdumpctl estimate` command directly, it will generate a report
+like this:
```
- Encrypted kdump target requires extra memory, assuming using the keyslot with
minimun memory requirement
-
- Reserved crashkernel: 256M
- Recommended crashkernel: 655M
-
- Kernel image size: 47M
- Kernel modules size: 12M
- Initramfs size: 19M
- Runtime reservation: 64M
- LUKS required size: 512M
- Large modules:
- xfs: 1892352
- nouveau: 2318336
- WARNING: Current crashkernel size is lower than recommended size 655M.
+NOTE: Encrypted kdump target requires extra memory, assuming using the keyslot with the
minimum memory requirement
+
+Reboot estimation:
+ Last estimation: Wed Sep 22 01:38:48 PM EDT 2021
+ Kernel version: 5.13.8-200.fc34.x86_64
+ Estimate took: 51s
+ Boosted crashkernel: 820M
+
+ Cached memory usage: 99M
+ Uncached memory usage: 125M
+ Reserved memory: 63M
+
+ Average runtime memory usage: 177M
+
+First kernel based estimation:
+ Reserved crashkernel: 820M
+
+ Kernel image size: 49M
+ Kernel modules size: 9M
+ Initramfs size: 20M
+ Runtime reservation: 64M
+ LUKS required size: 512M
+ Large modules:
+ xfs: 1908736
+ nouveau: 2318336
+
+Recommended crashkernel: 708M
+
+WARNING: Current crashkernel size is lower than recommended size 708M.
```
-It will generate a summary report about the estimated memory consumption
-of each component of kdump. The value may not be accurate enough, but
-would be a good start for finding a suitable crashkernel value.
+This report is composed of two parts:
+
+- First kernel based estimation:
+
+This estimation can estimate the crashkernel value without actually triggering
+kdump, it's based on the collectible info in first kernel, eg. kdump resource
+file size, kernel modules size. The value may not be accurate enough but would
+be a good start for finding a suitable crashkernel value.
+
+- Reboot estimation
+
+This estimation result is based on a real kdump run, which is more reliable but
+users has to collect and update the estimate by running this command:
+
+ `kdumpctl estimate --reboot`.
+
+This will have to reset your system multiple times to trigger kdump and collect
+the result.
+
+A reboot estimation run is composed of three stages:
+
+Reboot stage: Kdump estimation will have to temporarily boost the crashkernel
+value via a reboot first. This reboot is done via kexec to speed up the
+estimation progress. You can change this to hard reboot with `--hard-reboot`
+option if kexec doesn't work for your system.
+
+Panic stage: The machine is rebooted and crashkernel value is updated, a panic
+will be triggered. Kdump will catch the panic, and during this kdump run, extra
+Infos are captured for estimating kdump memory usage.
+
+Final stage: After the kdump dump progress is finished, the machine will reboot
+back into normal status again. Kdump service will collect the captured info, and
+estimation is done.
--
2.31.1