summaryrefslogtreecommitdiff
path: root/arch/powerpc/kernel/fadump.c
diff options
context:
space:
mode:
authorPingfan Liu <kernelfans@gmail.com>2020-04-01 22:00:44 +0800
committerMichael Ellerman <mpe@ellerman.id.au>2020-06-02 20:59:05 +1000
commitbe5470e0c285a68dc3afdea965032f5ddc8269d7 (patch)
tree7661dabaeee89965efff8c8563fde8bdff5493f9 /arch/powerpc/kernel/fadump.c
parentef3534a94fdbdeab4c89d18d0164be2ad5d6dbb7 (diff)
powerpc/crashkernel: Take "mem=" option into account
'mem=" option is an easy way to put high pressure on memory during some test. Hence after applying the memory limit, instead of total mem, the actual usable memory should be considered when reserving mem for crashkernel. Otherwise the boot up may experience OOM issue. E.g. it would reserve 4G prior to the change and 512M afterward, if passing crashkernel="2G-4G:384M,4G-16G:512M,16G-64G:1G,64G-128G:2G,128G-:4G", and mem=5G on a 256G machine. This issue is powerpc specific because it puts higher priority on fadump and kdump reservation than on "mem=". Referring the following code: if (fadump_reserve_mem() == 0) reserve_crashkernel(); ... /* Ensure that total memory size is page-aligned. */ limit = ALIGN(memory_limit ?: memblock_phys_mem_size(), PAGE_SIZE); memblock_enforce_memory_limit(limit); While on other arches, the effect of "mem=" takes a higher priority and pass through memblock_phys_mem_size() before calling reserve_crashkernel(). Signed-off-by: Pingfan Liu <kernelfans@gmail.com> Reviewed-by: Hari Bathini <hbathini@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/1585749644-4148-1-git-send-email-kernelfans@gmail.com
Diffstat (limited to 'arch/powerpc/kernel/fadump.c')
0 files changed, 0 insertions, 0 deletions