Date:	Tue, 2 Apr 2013 07:45:36 -0700
From:	Yinghai Lu <yinghai@...nel.org>
To:	Vivek Goyal <vgoyal@...hat.com>
Cc:	"H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...e.hu>, WANG Chao <chaowang@...hat.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] kexec: use Crash kernel for Crash kernel low

On Tue, Apr 2, 2013 at 6:50 AM, Vivek Goyal <vgoyal@...hat.com> wrote:
> On Mon, Apr 01, 2013 at 06:11:38PM -0700, Yinghai Lu wrote:
>> On Mon, Apr 1, 2013 at 3:40 PM, Yinghai Lu <yinghai@...nel.org> wrote:
>> > On Mon, Apr 1, 2013 at 3:20 PM, H. Peter Anvin <hpa@...or.com> wrote:
>> >> On 04/01/2013 03:17 PM, Yinghai Lu wrote:
>> >>>
>> >>> And his last suggestion is just as his old second suggestion.
>> >>>
>> >>> I just check the code again, it looks it is easy to change it to support:
>> >>> 1. crashkernel=XM
>> >>> 2. crashkernel_high=XM
>> >>> 3. crashkernel_high=XM crashkernel_low=YM
>> >>>
>> >>
>> >> Yes... my objections that you are giving the user the headache of
>> >> dealing with this very much remains, but I don't think we have any good
>> >> options.  However, the <size>,<options>.... syntax is at least
>> >> extensible, which the above syntax is not.
>> >
>> > ok, will check crashkernel=XM,high
>>
>> Please check attached four patches that should get into upstream for 3.9.
>> I sent first and second before.
>> other two is addressing old kexec-tools with kdump on new kernel.
>
> Hi Yinghai,
>
> I think there is still little confusion. What does crashkernel=X,high
> mean. Currently it seems to mean that memory is allocated from region
> above 4G and if it is not available, allocation fails.
>
> I thought what would be more useful if it means that we start search
> for memory from higher range of addresses and continue down till we
> find a suitable memory area.
>
> That means memory could either come from higher memory regions (above
> 4G) or from low memory regions (below 4G) depending on how much physical
> RAM system has.
>
> Similary crashkernel=X or crashkernel=X,low will mean that we start
> scanning for free memory from low memory area first. And if sufficient
> amount of memory is not available below 4G, memory could very well
> come from above 4G.
>
> That way a distribution could decide its default memory requirement
> (say 128M) and they could simply say, crashkernel=128M or
> crashkernel=128M,high (depending on whether they support 64bit bzImage
> or not).
>
> To achieve the behavior where we want to enforce that memory either
> comes from low or high area only otherwise allocation fails, we could
> probably use.
>
> crashkernel=X,high_only
> crashkernel=X,low_only
>
> And crashkernel_low could be replaced with crashkernel=X,low_only
>
> I think it is reasonable to continue to reserve low memory automatically
> for swiotlb if crash memory reservation happens above 4G. Users should
> be able to opt out of it using crashkernel=0M,low_only.

No, that make the logic too complicated.

After those four patches:
if the user still use old kexec-tools, they are still with
crashkernel=X, nothing is changed.
if the user want to use crashkernel=X,high, they should update kexec-tools.
   when high is used, memblock will search from top to low.
   if the allocated one is above 4G, kernel will try to auto allocate
72M under 4G for swiotlb
       user could crashkernel=Y,low to change 72M to other value.

The whole point is:
1. keep the transition from old kexec-tools to new one.
2. keep thing unified when new kexec-tools is used: always high.

Thanks

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