From: WANG Chao <chaowang@redhat.com>
To: Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
Yinghai Lu <yinghai@kernel.org>,
Pekka Enberg <penberg@kernel.org>,
Jacob Shin <jacob.shin@amd.com>,
Andrew Morton <akpm@linux-foundation.org>,
Vivek Goyal <vgoyal@redhat.com>,
"Eric W. Biederman" <ebiederm@xmission.com>
Cc: kexec@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: [PATCH] x86, kdump: crashkernel=X try to reserve below 896M first, then try below 4G, then MAXMEM
Date: Mon, 14 Oct 2013 19:46:40 +0800 [thread overview]
Message-ID: <1381751200-27376-1-git-send-email-chaowang@redhat.com> (raw)
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
kexec-tools).
- 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 <chaowang@redhat.com>
---
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)
high ? CRASH_KERNEL_ADDR_HIGH_MAX :
CRASH_KERNEL_ADDR_LOW_MAX,
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_KERNEL_ADDR_HIGH_MAX,
+ crash_size, alignment);
if (!crash_base) {
pr_info("crashkernel reservation failed - No suitable area found.\n");
--
1.8.3.1
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next reply other threads:[~2013-10-14 11:47 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-14 11:46 WANG Chao [this message]
2013-10-14 18:54 ` [PATCH] x86, kdump: crashkernel=X try to reserve below 896M first, then try below 4G, then MAXMEM Yinghai Lu
2013-10-15 3:00 ` WANG Chao
2013-10-15 14:48 ` Vivek Goyal
2013-10-18 3:50 ` Yinghai Lu
2013-10-18 12:38 ` Vivek Goyal
2013-10-19 5:45 ` Yinghai Lu
2013-10-21 15:16 ` Vivek Goyal
2013-10-24 6:11 ` Yinghai Lu
2013-10-24 11:01 ` WANG Chao
2013-10-24 19:13 ` Yinghai Lu
2013-10-24 19:24 ` Vivek Goyal
2013-10-24 14:02 ` Vivek Goyal
2013-10-24 19:15 ` Yinghai Lu
2013-10-24 19:18 ` Vivek Goyal
2013-10-24 19:24 ` Yinghai Lu
2013-10-24 19:27 ` Vivek Goyal
2013-10-24 19:37 ` Vivek Goyal
2013-10-25 5:48 ` Yinghai Lu
2013-10-28 5:49 ` Dave Young
2013-10-28 5:51 ` Dave Young
2013-10-28 15:12 ` Vivek Goyal
2013-11-04 14:38 ` WANG Chao
2013-10-28 5:47 ` Dave Young
2013-10-24 19:04 ` Yinghai Lu
2013-10-28 6:43 ` WANG Chao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1381751200-27376-1-git-send-email-chaowang@redhat.com \
--to=chaowang@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=ebiederm@xmission.com \
--cc=hpa@zytor.com \
--cc=jacob.shin@amd.com \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=penberg@kernel.org \
--cc=tglx@linutronix.de \
--cc=vgoyal@redhat.com \
--cc=yinghai@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox