Message-ID: <20131024140241.GA2322@redhat.com>
Date:	Thu, 24 Oct 2013 10:02:41 -0400
From:	Vivek Goyal <vgoyal@...hat.com>
To:	Yinghai Lu <yinghai@...nel.org>
Cc:	WANG Chao <chaowang@...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 Wed, Oct 23, 2013 at 11:11:51PM -0700, 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.

One could upgrade kexec-tools later. So Kernel does not know whether
user space is able to handle higher memory regions or not. So forcing
kernel to skip memory allocation does not sound right to me.

Also even with memory reserved high, old kexec-tools which can't deal
with it will fail anyway. So I don't agree that it is a problem.

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

Just because we have the facility to allocate memory starting from top, does
not mean that we should kill other options and force user to use this
option.

With crashkernel=X,high, a low memory will be reserved for swiotlb. And
I don't want that extra memory reservation. I am more than happy to
reserve memory below 4G and not do low memory reservation.


[..]
> Even we want to extend crashkernel=XM, then i would like to have
> it identical to crashkernel=XM,high instead.

You are assuming that crashkernel=xM,high is always good. I am arguing
that because it requires low memory reservation for swiotlb, when IOMMU
is not around, it will end up reserving more memory. So it is not
necessarily better than reserving memory below 4G.

Hence both crashkernel=xM and crashkernel=XM,high have their own usage.
We have been using crashkernel=xM and we know it works. So extending it
to be able to allocate memory from higher regions, if sufficient memory
is not available in lower regions makes sense. Memory reservation below
4G is more efficient due to not requiring swiotlb. And crashkernel=xM
has been working for us and users are familiar with it.

So I don't see a point that why would you try to block any move to
extend crashkernel=xM semantics.

Thanks
Vivek
--
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