From: ebiederm@xmission.com (Eric W. Biederman)
To: Amerigo Wang <amwang@redhat.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>
Subject: Re: [Patch 0/7] Implement crashkernel=auto
Date: Wed, 05 Aug 2009 19:47:56 -0700 [thread overview]
Message-ID: <m1y6pxr737.fsf@fess.ebiederm.org> (raw)
In-Reply-To: <4A7A3A78.7080200@redhat.com> (Amerigo Wang's message of "Thu\, 06 Aug 2009 10\:05\:44 +0800")
Amerigo Wang <amwang@redhat.com> writes:
> Eric W. Biederman wrote:
>> Neil Horman <nhorman@redhat.com> writes:
>>
>>> You could of
>>> course boot the installer kernel with a crashkernel line pre-selected suppose,
>>> but then you have to go to the trouble of figuring that allocation size out each
>>> time. This gives you a nice convienent way to get a reasonable block of memory
>>> without the need to do all that extra work.
>>>
>>
>> My big concern is that you are moving policy into the kernel, when it isn't at
>> all clear that policy is the right thing to do, and the existing mechanisms give
>> you enough rope to do this all in userspace.
>>
>
>
> How? This doesn't remove the existing mechanism, just provides a new choice for
> user like me who doesn't know how much memory should be reserved, or who simply
> doesn't want to concern this since he/she has very enough memory.
Having end users not caring is fine. My problem with this patch is that it
appears that no one is stepping up and taking responsibility for the crahsdump
mechanism, ensuring it will work, ensuring it will work for users. I see
us solving problems in the wrong place because people are not stepping
up and solving them in the proper place.
To actually use it there are much bigger problems then supplying the size
of the crashdump area.
My personal experience is that to make this work I had to list every kernel
module I needed in the order that they must be loaded, in /etc/kdump.conf
for my filesystem. I had to modify mkdumprd so that it actually generated
a dump ramdisk, and I think I am forgetting some other manual hack that
I had to use as well.
So if you have to do something manually I think the problem is user space,
and not the kernel.
In general I figure that whoever builds the kernel and initrd should be
responsible for testing and figuring out the amount of memory needed.
The primary kernel has no idea what is going to loaded in there and
as such no real idea how much memory is needed.
>> You also have to build (or at least load) the whole kdump image after
>> the system boots, and configure someplace for this to be saved.
>>
>> What class of problems do you expect to catch with this?
>>
>
> Again, try to save the user from choosing numbers for "crashkernel=".
The user being kernel developers? Whoever builds the kernel and initrd
should be responsible for testing and figuring this out.
In a distro context installers etc should be able to setup good defaults
so end users don't have to worry about this.
>> What has me puzzled is that the mkdumprd that ships with fedora isn't
>> usable without patching, and it seems to be steadily getting worse.
>
> Please explain why it is not usable? The patch won't break the userspace, since
> it modifies the "crashkernel=" command line dynamically.
No the crashdump mechanism is useless because user space is already
broken and unusable. At least on fedora and I assume by extension
redhat.
Eric
next prev parent reply other threads:[~2009-08-06 2:48 UTC|newest]
Thread overview: 46+ 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 ` [Patch 1/7] x86: add CONFIG_KEXEC_AUTO_RESERVE Amerigo Wang
2009-08-05 13:41 ` Neil Horman
2009-08-05 14:45 ` Andi Kleen
2009-08-05 20:07 ` Eric W. Biederman
2009-08-06 1:55 ` Amerigo Wang
2009-08-06 7:15 ` Andi Kleen
2009-08-06 7:44 ` 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 13:43 ` Neil Horman
2009-08-06 1:45 ` Amerigo Wang
2009-08-05 22:51 ` Yu, Fenghua
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 13:49 ` Neil Horman
2009-08-05 11:19 ` [Patch 4/7] ia64: implement crashkernel=auto Amerigo Wang
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 13:49 ` Neil Horman
2009-08-05 11:20 ` [Patch 6/7] powerpc: implement crashkernel=auto Amerigo Wang
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 13:33 ` [Patch 0/7] Implement crashkernel=auto Eric W. Biederman
2009-08-05 14:04 ` Neil Horman
2009-08-05 22:57 ` Eric W. Biederman
2009-08-06 2:05 ` Amerigo Wang
2009-08-06 2:47 ` Eric W. Biederman [this message]
2009-08-06 3:39 ` Amerigo Wang
2009-08-06 3:51 ` Eric W. Biederman
2009-08-06 5:57 ` Amerigo Wang
2009-08-06 6:14 ` Eric W. Biederman
2009-08-06 6:37 ` Amerigo Wang
2009-08-06 8:35 ` Eric W. Biederman
2009-08-06 8:47 ` Eric W. Biederman
2009-08-06 9:04 ` Amerigo Wang
2009-08-07 19:13 ` Bernhard Walle
2009-08-06 9:11 ` Amerigo Wang
2009-08-07 19:50 ` Eric W. Biederman
2009-08-07 21:03 ` Andi Kleen
2009-08-07 21:26 ` Bernhard Walle
2009-08-07 22:06 ` Eric W. Biederman
2009-08-07 21:31 ` Bernhard Walle
2009-08-07 22:16 ` Eric W. Biederman
2009-08-10 3:11 ` 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=m1y6pxr737.fsf@fess.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=akpm@linux-foundation.org \
--cc=amwang@redhat.com \
--cc=avorontsov@ru.mvista.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox