Re: [PATCH] x86, kdump: Set crashkernel_low automatically

["H. Peter Anvin" <hpa@zytor.com>]

On 03/11/2013 01:12 PM, Vivek Goyal wrote:
>>
>> Quite frankly the whole design seems to be held together with chewing
>> gum.  At the core, the problem is a tight coupling between kexec-tools
>> version, kexec-tools options, and kernel command line options that have
>> to be combined in very ugly ways.  Part of the reason is that the kernel
>> isn't actually given the information it needs to do the job required.
>>
>> As far as "if a user wants to load"... why on Earth should that be the
>> default?  How could that *not* be an exceptional case?
> 
> Because it breaks existing user cases. We had this limitation so far
> that bzImage has to be loaded in first 896MB. And for 32bit bzImage
> entry, I think that is still true?
> 
> So how can kernel assume that user is always loading a 64bit bzImage
> and reserve memory accordingly.
> 
> Also in the past we did not have relocatable kernel and memory had to
> be reserved at the address new kernel is built. Thankfully that is
> no more the case.
> 

The problem with this argument here is that we are spiraling down the
drain of increasing user-visible complexity in order to not break
existing but exotic use cases.  We need to stop and reverse this trend.
 I want to make a few observations on this:

1. Running with an archaic kexec-tools should be considered an anomaly.
 If necessary, we could introduce a kernel option to let the kernel know
which kexec-tools version the user will use.

2. As long as memory is available, there is always the option to shift
memory around to accommodate the crashkernel.  That probably should have
been done all along.

3. The memory size reserved should be deduced automatically to the
greatest possible extent.

	-hpa