Device dump may use a log of memory and cause OOM issue, so append
"novmcoredd" option for second kernel and disable it by default.
To use device dump, user should remove the vmcoredd parameter
manually.
Signed-off-by: Kairui Song <kasong@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Looking at the difference of the x86_64 and aarch64 kdump.sysconfig
options for Fedora, one can see the following options which are
different:
Present in kdump.sysconfig.x86_64 but not in kdump.sysconfig.aarch64:
---------------------------------------------------------------------
cgroup_disable=memory
mce=off
numa=off
udev.children-max=2
panic=10
acpi_no_memhotplug
transparent_hugepage=never
nokaslr
Present in kdump.sysconfig.aarch64 but not in kdump.sysconfig.x86_64:
---------------------------------------------------------------------
swiotlb=noforce
After going through all the options, it makes sense to add the
following options added to kdump.sysconfig.aarch64:
KDUMP_COMMANDLINE_APPEND="cgroup_disable=memory udev.children-max=2
panic=10 irqpoll nr_cpus=1
swiotlb=noforce reset_devices"
This has helped reduce the memory footprint of crashkernel on several
aarch64 machines available in the beaker lab. For e.g. I was seeing
OOM issues on large aws ec2 instances with the default crashkernel size
of 512M, and I had to use an increased crashkernel size of 786M on the
same to boot the crash dump kernel.
Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com>
Acked-by: Pingfan Liu <piliu@redhat.com>
'maxcpus' setting normally don't work on several kdump enabled systems
due to a known udev issue.
Currently the fedora kdump configuration is set as the following on the
aarch64 systems:
# cat /etc/sysconfig/kdump
<..snip..>
# This variable lets us append arguments to the current kdump
# commandline after processed by KDUMP_COMMANDLINE_REMOVE
# KDUMP_COMMANDLINE_APPEND="irqpoll maxcpus=1 reset_devices"
<..snip..>
Since the 'maxcpus' setting doesn't limit the number of SMP CPUs,
so the kdump kernel still boots with all CPUs available on the system.
For e.g on the qualcomm amberwing its 46 CPUs:
# lscpu
Architecture: aarch64
Byte Order: Little Endian
CPU(s): 46
On-line CPU(s) list: 0-45
Thread(s) per core: 1
Core(s) per socket: 46
Socket(s): 1
NUMA node(s): 1
Vendor ID: Qualcomm
Model: 1
Model name: Falkor
Stepping: 0x0
CPU max MHz: 2600.0000
CPU min MHz: 600.0000
BogoMIPS: 40.00
L1d cache: 32K
L1i cache: 64K
L2 cache: 512K
L3 cache: 58880K
NUMA node0 CPU(s): 0-45
Flags: fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid asimdrdm
This causes the memory consumption in the kdump kernel to swell up and
we can end up having OOM issues in the kdump kernel boot.
Whereas if we use 'nr_cpus=1' in the bootargs, the number of SMP CPUs in
the kdump kernel get limited to 1.
The 'swiotlb=noforce' setting in bootargs provide us extra guarding, to
ensure the crash kernel size requirements do not swell on systems
which support swiotlb.
With the above settings, crashkernel boots properly (without OOM) on all
the aarch64 boards I could test on - qualcomm amberwings, hp-moonshots
and hpe-apache (thunderx2) for crash dump saving on local disk.
Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com>
Acked-by: Pingfan Liu <piliu@redhat.com>
