Message-ID: <87hakhk6xu.fsf@xmission.com>
Date:	Mon, 11 Mar 2013 13:38:53 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Vivek Goyal <vgoyal@...hat.com>, Yinghai Lu <yinghai@...nel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...nel.org>,
	WANG Chao <chaowang@...hat.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86, kdump: Set crashkernel_low automatically

"H. Peter Anvin" <hpa@...or.com> writes:

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

Sure.  Running with the last release of kexec-tools before new changes
were made is not at all unreasonable, as updating both tools in sync is
a practical problem.

Having thought about this a little more with no changes and reserving
memory high we can run with any memory location we want as the syntax
crashkernel=AMOUNT@LOC is still supported.

A distro may not be able to automate that but shrug, a distro can
upgrade to the latest and greatest version of the tools assuming
those tools can support loading high.

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

Arguable.  The core strategy is to reserve memory at the beginning of
time so we have memory that we know has never been used for DMA, so
there is a very strong chance that memory will never be the target of
a DMA operation.  The expectation is that we do the shifting around at
boot time.

I doubt we have a mechanism in place that can actually shift around
memory in the quantities some people are after, after a system boots.

Now quite frankly I think there are some very silly things going on.
Why does makedumpfile need to allocate and create a huge bitmap of
which pages to dump?

Last I was playing with this I had my amount of reserved memory down to
32MiB or was it 8MiB.  It was very small and for the small system I was
on it worked fine.

I totally makes sense to figure out how to load a kernel high.  I am not
convinced kexec on panic is the best use of that ability.  I would argue
that it might be better to figure out how to use a small memory
foot-print and try to keep that foot-print from growing.

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