From: Amerigo Wang <amwang@redhat.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Neil Horman <nhorman@redhat.com>,
linux-kernel@vger.kernel.org, tony.luck@intel.com,
linux-ia64@vger.kernel.org, akpm@linux-foundation.org,
Ingo Molnar <mingo@elte.hu>,
Anton Vorontsov <avorontsov@ru.mvista.com>,
Andi Kleen <andi@firstfloor.org>
Subject: Re: [Patch 0/7] Implement crashkernel=auto
Date: Thu, 06 Aug 2009 09:11:48 +0000 [thread overview]
Message-ID: <4A7A9E54.60705@redhat.com> (raw)
In-Reply-To: <m1iqh1nxv3.fsf@fess.ebiederm.org>
Eric W. Biederman wrote:
> Amerigo Wang <amwang@redhat.com> writes:
>
>> Yes, exactly, in fact I am doing another part which will allow us to take back
>> of the reserved memory at run-time.
>>
>
> Alright. Let's look at that.
>
> I would make the restriction you can't resize the area while a kexec
> on panic image is loaded, and growing the area would not be a
> realistic option.
>
>
Sure, I have no plan to do growing reserved memory at run-time... only
freeing or shrinking it...
> If crash_kernel=auto happens in the context of being able to shrink
> the area from user space the definition is simple. We reserve as much
> memory as we think we can without affecting performance, stability,
> reliability.
>
> We can use an initial approximation of perhaps 1/32nd of low memory
> (aka directly mapped memory), and I don't see a point in making the
> code arch dependent at all. We should run the size approximation past
> the folks on linux-mm as they are more likely to know how much memory
> reduction we can tolerate without problems.
>
>
Yup, agreed.
> We can then plan on user space saying hey that is more than I need:
> shrink that, and load the kexec on panic kernel.
>
Exactly... but the interface still needs to be discussed...
Currently, we have two options:
1) add a new flag to kexec_load(2) to tell the kernel to shrink the memory;
2) use /proc/iomem, let the user to decide which and how much of the
reserved memory should be removed.
Any thoughts?
Thanks.
WARNING: multiple messages have this Message-ID (diff)
From: Amerigo Wang <amwang@redhat.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Neil Horman <nhorman@redhat.com>,
linux-kernel@vger.kernel.org, tony.luck@intel.com,
linux-ia64@vger.kernel.org, akpm@linux-foundation.org,
Ingo Molnar <mingo@elte.hu>,
Anton Vorontsov <avorontsov@ru.mvista.com>,
Andi Kleen <andi@firstfloor.org>
Subject: Re: [Patch 0/7] Implement crashkernel=auto
Date: Thu, 06 Aug 2009 17:11:48 +0800 [thread overview]
Message-ID: <4A7A9E54.60705@redhat.com> (raw)
In-Reply-To: <m1iqh1nxv3.fsf@fess.ebiederm.org>
Eric W. Biederman wrote:
> Amerigo Wang <amwang@redhat.com> writes:
>
>> Yes, exactly, in fact I am doing another part which will allow us to take back
>> of the reserved memory at run-time.
>>
>
> Alright. Let's look at that.
>
> I would make the restriction you can't resize the area while a kexec
> on panic image is loaded, and growing the area would not be a
> realistic option.
>
>
Sure, I have no plan to do growing reserved memory at run-time... only
freeing or shrinking it...
> If crash_kernel=auto happens in the context of being able to shrink
> the area from user space the definition is simple. We reserve as much
> memory as we think we can without affecting performance, stability,
> reliability.
>
> We can use an initial approximation of perhaps 1/32nd of low memory
> (aka directly mapped memory), and I don't see a point in making the
> code arch dependent at all. We should run the size approximation past
> the folks on linux-mm as they are more likely to know how much memory
> reduction we can tolerate without problems.
>
>
Yup, agreed.
> We can then plan on user space saying hey that is more than I need:
> shrink that, and load the kexec on panic kernel.
>
Exactly... but the interface still needs to be discussed...
Currently, we have two options:
1) add a new flag to kexec_load(2) to tell the kernel to shrink the memory;
2) use /proc/iomem, let the user to decide which and how much of the
reserved memory should be removed.
Any thoughts?
Thanks.
next prev parent reply other threads:[~2009-08-06 9:11 UTC|newest]
Thread overview: 99+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-05 11:19 [Patch 0/7] Implement crashkernel=auto Amerigo Wang
2009-08-05 11:19 ` Amerigo Wang
2009-08-05 11:19 ` [Patch 1/7] x86: add CONFIG_KEXEC_AUTO_RESERVE Amerigo Wang
2009-08-05 11:19 ` Amerigo Wang
2009-08-05 13:41 ` Neil Horman
2009-08-05 13:41 ` Neil Horman
2009-08-05 14:45 ` Andi Kleen
2009-08-05 14:45 ` Andi Kleen
2009-08-05 20:07 ` Eric W. Biederman
2009-08-05 20:07 ` Eric W. Biederman
2009-08-06 1:55 ` Amerigo Wang
2009-08-06 1:55 ` Amerigo Wang
2009-08-06 7:15 ` Andi Kleen
2009-08-06 7:15 ` Andi Kleen
2009-08-06 7:44 ` Amerigo Wang
2009-08-06 7:44 ` Amerigo Wang
2009-08-06 7:56 ` Amerigo Wang
2009-08-06 7:56 ` Amerigo Wang
2009-08-05 11:19 ` [Patch 2/7] x86: implement crashkernel=auto Amerigo Wang
2009-08-05 11:19 ` Amerigo Wang
2009-08-05 13:43 ` Neil Horman
2009-08-05 13:43 ` Neil Horman
2009-08-06 1:45 ` Amerigo Wang
2009-08-06 1:45 ` Amerigo Wang
2009-08-05 22:51 ` Yu, Fenghua
2009-08-05 22:51 ` Yu, Fenghua
2009-08-06 1:56 ` Amerigo Wang
2009-08-06 1:56 ` Amerigo Wang
2009-08-05 11:19 ` [Patch 3/7] ia64: add CONFIG_KEXEC_AUTO_RESERVE Amerigo Wang
2009-08-05 11:19 ` Amerigo Wang
2009-08-05 13:49 ` Neil Horman
2009-08-05 13:49 ` Neil Horman
2009-08-05 11:19 ` [Patch 4/7] ia64: implement crashkernel=auto Amerigo Wang
2009-08-05 11:19 ` Amerigo Wang
2009-08-05 13:46 ` Neil Horman
2009-08-05 13:46 ` Neil Horman
2009-08-05 11:19 ` [Patch 5/7] powerpc: add CONFIG_KEXEC_AUTO_RESERVE Amerigo Wang
2009-08-05 11:19 ` Amerigo Wang
2009-08-05 13:49 ` Neil Horman
2009-08-05 13:49 ` Neil Horman
2009-08-05 11:20 ` [Patch 6/7] powerpc: implement crashkernel=auto Amerigo Wang
2009-08-05 11:20 ` Amerigo Wang
2009-08-05 13:50 ` Neil Horman
2009-08-05 13:50 ` Neil Horman
2009-08-05 11:20 ` [Patch 7/7] doc: update the kdump document Amerigo Wang
2009-08-05 11:20 ` Amerigo Wang
2009-08-05 13:33 ` [Patch 0/7] Implement crashkernel=auto Eric W. Biederman
2009-08-05 13:33 ` Eric W. Biederman
2009-08-05 14:04 ` Neil Horman
2009-08-05 14:04 ` Neil Horman
2009-08-05 22:57 ` Eric W. Biederman
2009-08-05 22:57 ` Eric W. Biederman
2009-08-06 2:05 ` Amerigo Wang
2009-08-06 2:05 ` Amerigo Wang
2009-08-06 2:47 ` Eric W. Biederman
2009-08-06 2:47 ` Eric W. Biederman
2009-08-06 3:39 ` Amerigo Wang
2009-08-06 3:39 ` Amerigo Wang
2009-08-06 3:51 ` Eric W. Biederman
2009-08-06 3:51 ` Eric W. Biederman
2009-08-06 5:57 ` Amerigo Wang
2009-08-06 5:57 ` Amerigo Wang
2009-08-06 6:14 ` Eric W. Biederman
2009-08-06 6:14 ` Eric W. Biederman
2009-08-06 6:37 ` Amerigo Wang
2009-08-06 6:37 ` Amerigo Wang
2009-08-06 8:35 ` Eric W. Biederman
2009-08-06 8:35 ` Eric W. Biederman
2009-08-06 8:47 ` Eric W. Biederman
2009-08-06 8:47 ` Eric W. Biederman
2009-08-06 9:04 ` Amerigo Wang
2009-08-06 9:04 ` Amerigo Wang
2009-08-07 19:13 ` Bernhard Walle
2009-08-07 19:13 ` Bernhard Walle
2009-08-06 9:11 ` Amerigo Wang [this message]
2009-08-06 9:11 ` Amerigo Wang
2009-08-07 19:50 ` Eric W. Biederman
2009-08-07 19:50 ` Eric W. Biederman
2009-08-07 19:50 ` Eric W. Biederman
2009-08-07 21:03 ` Andi Kleen
2009-08-07 21:03 ` Andi Kleen
2009-08-07 21:03 ` Andi Kleen
2009-08-07 21:26 ` Bernhard Walle
2009-08-07 21:26 ` Bernhard Walle
2009-08-07 21:26 ` Bernhard Walle
2009-08-07 22:06 ` Eric W. Biederman
2009-08-07 22:06 ` Eric W. Biederman
2009-08-07 22:06 ` Eric W. Biederman
2009-08-07 21:31 ` Bernhard Walle
2009-08-07 21:31 ` Bernhard Walle
2009-08-07 21:31 ` Bernhard Walle
2009-08-07 22:16 ` Eric W. Biederman
2009-08-07 22:16 ` Eric W. Biederman
2009-08-07 22:16 ` Eric W. Biederman
2009-08-10 3:11 ` Amerigo Wang
2009-08-10 3:11 ` Amerigo Wang
2009-08-10 3:11 ` Amerigo Wang
2009-08-06 1:39 ` Amerigo Wang
2009-08-06 1:39 ` Amerigo Wang
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=4A7A9E54.60705@redhat.com \
--to=amwang@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=avorontsov@ru.mvista.com \
--cc=ebiederm@xmission.com \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=nhorman@redhat.com \
--cc=tony.luck@intel.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 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.