From: Vivek Goyal <vgoyal@redhat.com>
To: Yinghai Lu <yinghai@kernel.org>
Cc: WANG Chao <chaowang@redhat.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
Pekka Enberg <penberg@kernel.org>,
Jacob Shin <jacob.shin@amd.com>,
Andrew Morton <akpm@linux-foundation.org>,
"Eric W. Biederman" <ebiederm@xmission.com>,
"kexec@lists.infradead.org" <kexec@lists.infradead.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] x86, kdump: crashkernel=X try to reserve below 896M first, then try below 4G, then MAXMEM
Date: Fri, 18 Oct 2013 08:38:37 -0400 [thread overview]
Message-ID: <20131018123837.GB2277@redhat.com> (raw)
In-Reply-To: <CAE9FiQXVCx__SuhAdO9_CNaRncW2HB2tv3UjZrQcbsTV35QWow@mail.gmail.com>
On Thu, Oct 17, 2013 at 08:50:07PM -0700, Yinghai Lu wrote:
[..]
> > Previously high reservation (reservation above 896M) will anyway fail. So
> > instead of failing, if we try reservation in higher memory areas why that
> > would break old kexec-tools?
>
> If thel old kexec-tools would fail, we should let them fail early as possible,
> do not reserve at first point.
A user does not care if they get the message "memory nor reserved" or if
they get the message that "could not find a suitable memory hole at
address X".
>
> >
> > IOW, previously anyway kexec-tools will not work as no memory will be
> > reserved in higher memory area. Now memory will be reserved but old
> > kexec-tools should fail as it can't load in that area.
> >
> > If that works, then one would use crashkernel=X,high only if he is
> > particualr that memory reservation comes from area above 4G (despite
> > the fact that same memory could have been reserved below 4G too).
>
> My point:
> Push user to use ",high" as more as possible, so we only to handle one
> path eventually.
> for old kernel, leave them to use old grammer. do not need to change it.
I don't understand this. Why we should push users to use ",high" syntax.
That is an option. Those who want to use it, should use it.
We have been using crashkernel=XM for a long time now. And it makes sense
to extend this option to be able to reserve memory at higher addresses
if asked memory is not available at lower addresses.
You are not thinking about ease of use here for existing users.
>
> Also boot loader should always have different entry for old kernel and
> new kernel.
What does memory reservation location has to do with kernel entry point?
If it is a 64bit bzImage, we will use 64bit entry point by default, isn't
it? Does not matter whether memory is reserved above 4G or not.
I think it makes sense that existing crashkernel=XM usres be able to
reserve memory in higher memory area if sufficient memory is not available
below 896M or below 4G. Those who always want memory reservation above 4G
they should use ",high" syntax and enforce memory allocation above 4G.
Thanks
Vivek
next prev parent reply other threads:[~2013-10-18 12:39 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-14 11:46 [PATCH] x86, kdump: crashkernel=X try to reserve below 896M first, then try below 4G, then MAXMEM WANG Chao
2013-10-14 18:54 ` 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 [this message]
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=20131018123837.GB2277@redhat.com \
--to=vgoyal@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=chaowang@redhat.com \
--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=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