[lkml]   [2009]   [Aug]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [Patch 0/8] V5 Implement crashkernel=auto
Michael Ellerman <> writes:

> On Wed, 2009-08-26 at 23:15 -0400, Amerigo Wang wrote:
>> V4 -> V5:
>> - Rename the global functions, as suggested by Andrew.
>> - Save some macros, as suggested by Andrew.
>> - Change the high threshold, from 32G to 4G.
>> - Change the low threshold on ppc, suggested by ppc developers.
>> - Make the mm part as a seperate function, suggest by Eric.
>> - Make the IA64 code more readable.
>> - Reorder the patchset again, since review from mm people is done.
>> V3 -> V4:
>> - Reorder the patches.
>> - Really free the reserved memory, instead of remapping it.
>> (Thanks to KAMEZAWA Hiroyuki!)
>> - Release the reserved memory resource when the size is 0.
>> - Use strict_strtoul() instead of simple_strtoul().
>> V2 -> V3:
>> - Use more clever way to calculate reserved memory size, especially for IA64.
>> - Add that patch that implements shrinking reserved memory
>> V1 -> V2:
>> - Use include/asm-generic/kexec.h, suggested by Neil.
>> - Rename a local variable, suggested by Fenghua.
>> - Fix some style problems found by
>> - Unify the Kconfig docs.
>> 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/8 which contains an update for the documentation.
>> Patch 8/8 implements shrinking reserved memory at run-time, which is useful
>> when more than enough memory is reserved automatically.
>> This patchset _is_ already tested on x86_64, IA64 and ppc64.
> I don't want to sound like a micro-kernel zealot, I'm not, but I'm still
> unconvinced as to why the auto logic needs to go in the kernel. What is
> the compelling reason that the kernel needs to do this calculation vs
> some userspace tool? We already have the syntax that allows defining a
> different crash size depending on the size of RAM.
> The shrinking of reserved memory is cool.

Michael I am in agreement with you.
The shrinking is good.

If we can come up with some simple and generic logic that we can use
to reserve memory then I am in favor. However all this patchset is
doing is moving user space specific arbitrary hacks into the kernel we
do that perfectly well on the command line. Having the amount to
reserve be arch specific is complete non-sense and a major maintenance


 \ /
  Last update: 2009-08-31 05:05    [W:0.108 / U:7.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site