Re: [Patch 0/7] Implement crashkernel=auto

[Eric W. Biederman]

Neil Horman <nhorman@xxxxxxxxxx> writes:

> On Wed, Aug 05, 2009 at 06:33:57AM -0700, Eric W. Biederman wrote:
>> Amerigo Wang <amwang@xxxxxxxxxx> writes:
>> 
>> > This series of patch implements automatically reserved memory for crashkernel,
>> > by introducing a new boot option "crashkernel=auto". This idea is from Neil.
>> >
>> > In case of breaking user-space applications, it modifies this boot option after
>> > it decides how much memory should be reserved.
>> >
>> > On different arch, the threshold and reserved memory size is different. Please
>> > refer patch 7/7 which contains an update for the documentation.
>> >
>> > Note: This patchset was only tested on x86_64 with differernt memory sizes.
>> 
>> This seems like a silly hard code. Especially for a feature distros don't
>> care enough about to implement a working initrd for.
>> 
>> Has anyone bothered to justify those large amounts of memory?
>> Where does the 128M go?
>> 
>> Please pardon me for being a cynic but I don't see the command line option
>> being the bottleneck for real users to make this work.
>> 
>> Eric
>
> Lots of the impetus behind this results from a desire to have kexec configured
> and setup up during install.  Having the kernel allocate a default size block of
> RAM lets you do that without the need for an interim reboot.

I assume you mean kexec on panic.  kexec should be fine and you can arguably
solve this problem with a little bit of userspace glue and a kexec of yourself
during bootup.

> 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.

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?

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.  If the
concern was about getting better bug reports I would expect getting this
functionality into fedora would be where you would be focusing your efforts.

Am I missing something obvious?

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/