Commit Graph

3 Commits

Author SHA1 Message Date
Kairui Song
ff329689b3 Disable device dump by default
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>
2019-09-02 17:06:09 +08:00
Bhupesh Sharma
fd1eccf920 aarch64/kdump.sysconfig: Make config options similar to x86_64
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>
2019-05-29 17:04:27 +08:00
Bhupesh Sharma
3001788f4c Add aarch64 specific kdump.sysconfig and use 'nr_cpus' instead of 'maxcpus'
'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>
2019-05-29 17:04:20 +08:00