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

From: Amerigo Wang
Date: Wed Aug 05 2009 - 23:38:00 EST


Eric W. Biederman wrote:
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.

Yeah, that is exactly why I _didn't_ pick the idea of reserving memory automatically and silently without "crashkernel=auto".

If a user specifies "crashkernel=auto", that means he/she has no idea how much memory to be reserved, he/she wants to let the kernel to decide. Kernel should know better than the user in this situation.

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.

For kernel developers, "crashkernel=auto" should save a lot. You seem agree with this one.

For users, they rely on the distro which can always specify "crashkernel=auto" now, not different numbers for different arch, since "crashkernel=auto" is designed to be safe for all cases. Also saves many work...

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.

Again, why broken?

Thanks.


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