From: Simon Horman <horms@verge.net.au>
To: "M. Mohan Kumar" <mohan@in.ibm.com>
Cc: Bernhard Walle <bernhard@bwalle.de>,
kexec@lists.infradead.org, ppcdev <linuxppc-dev@ozlabs.org>
Subject: Re: [PATCH] Reserve memory for kdump kernel within RMO region
Date: Fri, 27 Nov 2009 22:51:59 +1100 [thread overview]
Message-ID: <20091127115155.GA19070@verge.net.au> (raw)
In-Reply-To: <4B0F8F62.3050000@in.ibm.com>
On Fri, Nov 27, 2009 at 02:05:46PM +0530, M. Mohan Kumar wrote:
> On 11/27/2009 12:56 AM, Bernhard Walle wrote:
> >M. Mohan Kumar schrieb:
> >>On 11/26/2009 12:22 AM, Bernhard Walle wrote:
> >>>M. Mohan Kumar schrieb:
> >>>>Reserve memory for kdump kernel within RMO region
> >>>>
> >>>>When the kernel size exceeds 32MB(observed with some distros), memory
> >>>>for kdump kernel can not be reserved as kdump kernel base is assumed to
> >>>>be 32MB always. When the kernel has CONFIG_RELOCATABLE option enabled,
> >>>>provide the feature to reserve the memory for kdump kernel anywhere in
> >>>>the RMO region.
> >>
> >>Hi Bernhard,
> >>
> >>>Correct me if I'm wrong, but: CONFIG_RELOCATABLE is for the kernel that
> >>>gets loaded as crashkernel, not for the kernel that loads the
> >>>crashkernel. So it would be perfectly fine that a kernel that has not
> >>>CONFIG_RELOCATABLE set would load another kernel that has
> >>>CONFIG_RELOCATABLE set on an address != 32 M.
> >>
> >>No, with relocatable option, the same kernel is used as both production
> >>and kdump kernel.
> >
> >Can be, but it's not strictly necessary. It depends what userland does.
> >Especially it's possible that a non-relocatable, self-compiled kernel
> >loads a relocatable distribution kernel as capture kernel.
> >
>
> I don't understand why a non-relocatable kernel will use relocatable
> kernel for capturing kdump kernel. The idea for relocatable kernel
> is to avoid using two different kernels to capture kernel dump.
True, but that doesn't necessarily mean that using a relocatable
kdump kernel is required. Well, hopefully not.
> >Also, it would make sense to make the behaviour symmetric across
> >platforms. Currently we have:
> >
> > - x86 and ia64: Without offset on command line, use any offset
> > With offset on command line, use that offset and fail
> > if no memory is available at that offset.
> > - ppc64: Always use 32M and ignore the offset.
> >
> >If your patch gets applied, we have:
> >
> > - ppc64: With CONFIG_RELOCATABLE, use any offset
> > With offset on command
> >
> >I don't see why the behaviour on ppc64 should be completely different.
> >
> >Having maintained kdump for SUSE for x86, ia64 and partly ppc64 in the
> >past, I always felt that ppc64 is more different from x86 than ia64 is
> >from x86. That's one more step into that direction without a technical
> >reason.
>
> Also with the crashkernel=auto parameter (patches are not yet
> merged), the crashkernel base (offset) by default would be 32MB. In
> this case if a kernel passed with crashkernel=auto and if the first
> kernel size exceeds 32MB, memory for kdump kernel will always fail.
>
> >
> >Having that all said: If your patch gets in mainline kernel, than we
> >should change the behaviour also for x86 and ia64.
> >
> >
> >
> >Regards,
> >Bernhard
>
>
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2009-11-27 11:52 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-25 13:17 [PATCH] Reserve memory for kdump kernel within RMO region M. Mohan Kumar
2009-11-25 18:52 ` Bernhard Walle
2009-11-26 11:12 ` M. Mohan Kumar
2009-11-26 19:26 ` Bernhard Walle
2009-11-27 8:35 ` M. Mohan Kumar
2009-11-27 11:51 ` Simon Horman [this message]
2009-11-27 12:54 ` M. Mohan Kumar
2009-11-27 18:39 ` Bernhard Walle
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=20091127115155.GA19070@verge.net.au \
--to=horms@verge.net.au \
--cc=bernhard@bwalle.de \
--cc=kexec@lists.infradead.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=mohan@in.ibm.com \
/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;
as well as URLs for NNTP newsgroup(s).