[lkml]   [2013]   [Oct]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Patch in this message
Subject[PATCH] x86, kdump: crashkernel=X try to reserve below 896M first, then try below 4G, then MAXMEM
Now crashkernel=X will fail out if there's not enough memory at
low (below 896M). What makes sense for crashkernel=X would be:

- First try to reserve X below 896M (for being compatible with old
- If fails, try to reserve X below 4G (swiotlb need to stay below 4G).
- If fails, try to reserve X from MAXMEM top down.

So that user can easily reserve large memory with crashkernel=X instead
of crashkernel=X,high. It's more transparent and user-friendly.

If crashkernel is large and the reserved is beyond 896M, old kexec-tools
won't be compatible with new kernel for most of time.

kexec will fail out immediately in this case. But the failure could be
expected, because old kexec users should not try to reserve that large
amount of memory at the first place.

On the other hand, old kexec also will fail on old kernel when there's
not enough low memory to reserve a large crash kernel area. So the
failure of old kexec is consistent between old kernel and new kernel.

Signed-off-by: WANG Chao <>
arch/x86/kernel/setup.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)

diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index f0de629..38e6c1f 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -593,6 +593,20 @@ static void __init reserve_crashkernel(void)
crash_size, alignment);
+ /*
+ * crashkernel=X reserve below 896M fails? Try below 4G
+ */
+ if (!high && !crash_base)
+ crash_base = memblock_find_in_range(alignment,
+ (1ULL << 32),
+ crash_size, alignment);
+ /*
+ * crashkernel=X reserve below 4G fails? Try MAXMEM
+ */
+ if (!high && !crash_base)
+ crash_base = memblock_find_in_range(alignment,
+ crash_size, alignment);

if (!crash_base) {
pr_info("crashkernel reservation failed - No suitable area found.\n");

 \ /
  Last update: 2013-10-14 14:01    [W:0.112 / U:0.276 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site