Message-ID: <20131024110117.GB3033@dhcp16-109.nay.redhat.com>
Date:	Thu, 24 Oct 2013 19:01:17 +0800
From:	WANG Chao <chaowang@...hat.com>
To:	Yinghai Lu <yinghai@...nel.org>
Cc:	Vivek Goyal <vgoyal@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Pekka Enberg <penberg@...nel.org>,
	Jacob Shin <jacob.shin@....com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	"kexec@...ts.infradead.org" <kexec@...ts.infradead.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] x86, kdump: crashkernel=X try to reserve below 896M
 first, then try below 4G, then MAXMEM

On 10/23/13 at 11:11pm, Yinghai Lu wrote:
> On Mon, Oct 21, 2013 at 8:16 AM, Vivek Goyal <vgoyal@...hat.com> wrote:
> > On Fri, Oct 18, 2013 at 10:45:43PM -0700, Yinghai Lu wrote:
> >
> >
> > IIUC, you are trying to say that with new kernel old kexec-tools will fail
> > at a different failure point. I don't see why that is a problem. It still
> > fails.
> 
> Yes, that could cause confusion.
> 
> We already knew it would fail possible at most later, we should make
> it skip allocation during first kernel booting.

It's said:

	crashkernel=size[KMG][@offset[KMG]]
			[KNL] Using kexec, Linux can switch to a 'crash kernel'
			upon panic. This parameter reserves the physical
			memory region [offset, offset + size] for that kernel
			image. If '@...set' is omitted, then a suitable offset
			is selected automatically. Check
			Documentation/kdump/kdump.txt for further details.

Nothing mentions that crashkernel=X is restricted to reserve at low.

It could be more confusing that crashkernel=X (say 1G) can not find a
suitable area while actually there's enough memory out there.

Current situation is the combination of crashkernel X/high/low is quite
complicated, it's more like supposed to be used by the pros.

Truth is, most user, after upgrading to new kernel, would want reserve
large by just changing to crashkernel=1G, not be forced to use a new
format craskernel=1G,high.

I think crashkernel=XM,high is really supposed to be used when user indeed
want to reserve from high.

Like Vivek said, failing at different point shouldn't be a problem.
That's an incorrect configuration. When crashkernel=1G,high, old
kexec-tools still fails the same way. That could cause confusion, in
your word.

Let me put it in an example, a user want to utilize this new kernel
feature to reserve 1G for crash kernel but not upgrade kexec-tools,

- W/o this patch:
 First he would try crashkernel=1G, but failed to reserve. Second time,
 he goes with crashkernel=1G,high, reservation is fine but kexec fails
 to load. Upgrading kexec-tools is essential to him.

- W/ this patch:
  First he would try crashkernel=1G, reservation is ok but kexec fails
  to load the same way as the case of crashkernel=1G,high. Upgrading
  kexec-tools is essential to him.

The point is old kexec-tools can't load high, no matter by what kind of
crashkernel cmdline to reserve at high.

> 
> >
> > [..]
> >> > You are not thinking about ease of use here for existing users.
> >>
> >> most existing user don't need to do anything. just with new kernel and
> >> old kexec tools.
> >>
> >> those system that did not work kexec before because XM is too big, they have to
> >> update kexec tools, and use ",high"
> >>
> >> Make it simple, less error.
> >
> > No, it is not that simple. Think from a distribution's perspective also.
> > We have the logic to scale reserved memory based on physical memory
> > present in the system. Now we are seeing bigger memory systems (which
> > would not have worked in the past). We still want to retain the existing
> > logic and not switch to crashkernel=x,high. One does not have to. It
> > makes life simpler.
> 
> distribution should go with ",high" for 64 bit kernel and new kexec-tools.
> for 32bit kernel, you still can have ",high" or not, as ",high" is ignored.

Why ",high" is becoming a default one instead of "XM"?

Isn't that the kernel's job to find a most suitable area at best guess
in this case? By this case, I mean kernel have no idea kexec-tools is
new or old.

> 
> 
> >
> > Same logic working both with smaller memory systems as well as large memory
> > systems. One should not have to choose a different command line because
> > there is more physical RAM present in the system.
> 
> ",high" is working even on smaller memory sytem.

Yeah, you're right.

> 
> >
> >>
> >> We already support above 4G, what is point for trying below 4G?
> >
> > Because it is not *required* to reserve memory above 4G. Because we want
> > same command line to work with both small memory systems as well as
> > large memory systems and we don't care whether memory is reserved below
> > 4G or above 4G. What does matter though that we don't have to worry about
> > switching command line option if it is large memory system.
> 
> ",high" will work smaller or large memory system after you install new
> kexec tools.
> 
> Again, for distribution, when new kernel is added, new kernel will all
> have ",high"
> and new kexec-tools get installed.
> 
> Even we want to extend crashkernel=XM, then i would like to have
> it identical to crashkernel=XM,high instead.

Why would you like crashkernel=XM is identical to crashkernel=XM,high?

That's not an option if you want new kernel to be compatible with old
kexec-tools.


Thanks
WANG Chao
--
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