From: "M. Mohan Kumar" <mohan@in.ibm.com>
To: Bernhard Walle <bernhard@bwalle.de>
Cc: michael@ellerman.id.au, benh@kernel.crashing.org,
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 14:05:46 +0530 [thread overview]
Message-ID: <4B0F8F62.3050000@in.ibm.com> (raw)
In-Reply-To: <4B0ED674.6050501@bwalle.de>
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.
> 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
WARNING: multiple messages have this Message-ID (diff)
From: "M. Mohan Kumar" <mohan@in.ibm.com>
To: Bernhard Walle <bernhard@bwalle.de>
Cc: 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 14:05:46 +0530 [thread overview]
Message-ID: <4B0F8F62.3050000@in.ibm.com> (raw)
In-Reply-To: <4B0ED674.6050501@bwalle.de>
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.
> 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
next prev parent reply other threads:[~2009-11-27 8:35 UTC|newest]
Thread overview: 16+ 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 13:17 ` M. Mohan Kumar
2009-11-25 18:52 ` Bernhard Walle
2009-11-25 18:52 ` Bernhard Walle
2009-11-26 11:12 ` M. Mohan Kumar
2009-11-26 11:12 ` M. Mohan Kumar
2009-11-26 19:26 ` Bernhard Walle
2009-11-26 19:26 ` Bernhard Walle
2009-11-27 8:35 ` M. Mohan Kumar [this message]
2009-11-27 8:35 ` M. Mohan Kumar
2009-11-27 11:51 ` Simon Horman
2009-11-27 11:51 ` Simon Horman
2009-11-27 12:54 ` M. Mohan Kumar
2009-11-27 12:54 ` M. Mohan Kumar
2009-11-27 18:39 ` Bernhard Walle
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=4B0F8F62.3050000@in.ibm.com \
--to=mohan@in.ibm.com \
--cc=benh@kernel.crashing.org \
--cc=bernhard@bwalle.de \
--cc=kexec@lists.infradead.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=michael@ellerman.id.au \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.