Message-ID: <m1y6pxr737.fsf@fess.ebiederm.org>
Date:	Wed, 05 Aug 2009 19:47:56 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Amerigo Wang <amwang@...hat.com>
Cc:	Neil Horman <nhorman@...hat.com>, linux-kernel@...r.kernel.org,
	tony.luck@...el.com, linux-ia64@...r.kernel.org,
	akpm@...ux-foundation.org, Ingo Molnar <mingo@...e.hu>,
	Anton Vorontsov <avorontsov@...mvista.com>
Subject: Re: [Patch 0/7] Implement crashkernel=auto

Amerigo Wang <amwang@...hat.com> writes:

> Eric W. Biederman wrote:
>> Neil Horman <nhorman@...hat.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists