From: Vivek Goyal <vgoyal@redhat.com>
To: Yinghai Lu <yinghai@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@elte.hu>,
"H. Peter Anvin" <hpa@zytor.com>, WANG Chao <chaowang@redhat.com>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 3/4] x86, kdump: Retore crashkernel= to allocate low
Date: Tue, 2 Apr 2013 16:11:48 -0400 [thread overview]
Message-ID: <20130402201148.GJ29506@redhat.com> (raw)
In-Reply-To: <CAE9FiQViU_X-idHyFmRFQXmP23oWN63XkAr3KmXsfys1VBR53g@mail.gmail.com>
On Tue, Apr 02, 2013 at 01:00:46PM -0700, Yinghai Lu wrote:
> On Tue, Apr 2, 2013 at 12:11 PM, Vivek Goyal <vgoyal@redhat.com> wrote:
> > On Tue, Apr 02, 2013 at 11:49:13AM -0700, Yinghai Lu wrote:
> >> On Tue, Apr 2, 2013 at 11:42 AM, Yinghai Lu <yinghai@kernel.org> wrote:
> >> > aka:
> >> > old kexec-tools stay with "crashkernel=X"
> >> > new kexec-tools stay with
> >> > 1. like old kexec tools
> >> > 2. or "crashkernel=X,high" or "crashkernel=X,high crashkernel=Y,low",
> >> > Y could be 100M or 0 etc.
> >>
> >> I keep the old logic like:
> >> if there are several "crashkernel=X,high", only last one is honored.
> >> if there are several "crashkernel=Y,low", only last one is honored.
> >
> > Yes but if different types of crashkernel= options are mixes then
> > behavior is not defined.
>
> dmesg or /proc/iomem will show them what is finally reserved.
>
> >
> > crashkernel=X,high crashkernel=X
>
> ==> crashkernel=X is tossed away.
You are just describing what your code does. There is no theme or
justification behind this behavior. There is no uniformity. A user can
question that so far you used to honor last crashkernel= parameter and
suddenly in 3.9 that's no more the case. Out of blue crashkernel=X,high is
overriding crashkernel=X and it is not obivious why.
>
> > crashkernel=X,high crashkernel=Y;low
>
> normal case. if user want more or disable low range.
Again, behavior is not clear to user. Please stop describing your code
behavior. Discuss more in terms of presenting a consistent interface to
user.
>
> > crashkernel=Y;low crashkernel=X
>
> crashkernel=X will be used.
Why? When crashkernel=X is specified with crashkernel=Y;high, high takes
over but when crashkernel=X is specified with crashkernel=Y;low,
crashkernel=X takes over. These is highly unintutive.
>
> >
> > And possibilities go on. So I think it makes life simpler if we always
> > parse last crashkernel= option and act upon that. And use
> > crashkernel_no_auto_low to opt out of auto reserved low memory area.
>
> No, that is not just disable. User could want more like 128M instead of 72M.
If user wants 128M in low memory, they will just specify
crashkernel=128M;low
If they want to control multiple ranges of memory, then that's the feature
we currently don't support. Currently we support only reserving one range
of memory.
If you want to support multiple ranges of memory,then do it properly.
Parse all crashkernel= options, prepare a list of memory to be reserved
and unreserved, resolve all the conflicts between various options and
then reserve the memory. But that does not seem to be a requirement at
this point of time.
Thanks
Vivek
next prev parent reply other threads:[~2013-04-02 20:12 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-02 17:19 [PATCH 0/4] x86, kdump: Fix crashkernel high with old kexec-tools Yinghai Lu
2013-04-02 17:19 ` [PATCH 1/4] x86, kdump: Set crashkernel_low automatically Yinghai Lu
2013-04-02 17:19 ` [PATCH 2/4] kexec: use Crash kernel for Crash kernel low Yinghai Lu
2013-04-02 17:19 ` [PATCH 3/4] x86, kdump: Retore crashkernel= to allocate low Yinghai Lu
2013-04-02 18:06 ` Vivek Goyal
2013-04-02 18:42 ` Yinghai Lu
2013-04-02 18:49 ` Yinghai Lu
2013-04-02 19:11 ` Vivek Goyal
2013-04-02 20:00 ` Yinghai Lu
2013-04-02 20:11 ` Vivek Goyal [this message]
2013-04-02 20:25 ` Vivek Goyal
2013-04-02 20:36 ` Yinghai Lu
2013-04-03 13:18 ` Vivek Goyal
2013-04-03 17:12 ` Yinghai Lu
2013-04-03 17:32 ` Yinghai Lu
2013-04-03 17:47 ` Vivek Goyal
2013-04-03 20:38 ` Yinghai Lu
2013-04-03 21:00 ` Vivek Goyal
2013-04-04 0:56 ` Yinghai Lu
2013-04-04 13:41 ` Vivek Goyal
2013-04-04 13:51 ` Vivek Goyal
2013-04-03 17:36 ` Vivek Goyal
2013-04-02 19:09 ` Vivek Goyal
2013-04-02 20:04 ` Yinghai Lu
2013-04-02 17:19 ` [PATCH] x86, kdump: Change crashkernel_high/low= to crashkernel=;high/low Yinghai Lu
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=20130402201148.GJ29506@redhat.com \
--to=vgoyal@redhat.com \
--cc=chaowang@redhat.com \
--cc=ebiederm@xmission.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--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