From: Vivek Goyal <vgoyal@redhat.com>
To: Yinghai Lu <yinghai@kernel.org>
Cc: "kexec@lists.infradead.org" <kexec@lists.infradead.org>,
Jacob Shin <jacob.shin@amd.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Pekka Enberg <penberg@kernel.org>, Ingo Molnar <mingo@redhat.com>,
"Eric W. Biederman" <ebiederm@xmission.com>,
"H. Peter Anvin" <hpa@zytor.com>,
Thomas Gleixner <tglx@linutronix.de>,
Andrew Morton <akpm@linux-foundation.org>,
WANG Chao <chaowang@redhat.com>
Subject: Re: [PATCH] x86, kdump: crashkernel=X try to reserve below 896M first, then try below 4G, then MAXMEM
Date: Thu, 24 Oct 2013 15:18:21 -0400 [thread overview]
Message-ID: <20131024191821.GE2322@redhat.com> (raw)
In-Reply-To: <CAE9FiQUu0WwMgNpog4TKch+MT2i7_DsNvqZxbyQusS4AFxdhQQ@mail.gmail.com>
On Thu, Oct 24, 2013 at 12:15:25PM -0700, Yinghai Lu wrote:
> On Thu, Oct 24, 2013 at 7:02 AM, Vivek Goyal <vgoyal@redhat.com> wrote:
> > On Wed, Oct 23, 2013 at 11:11:51PM -0700, Yinghai Lu wrote:
> >
> > 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.
>
> Make the thing simple.
> Keep them separately, leave crashkernel=xM to old kexec-tools mostly
> and keep crashkernel=xM,high to newer kexec-tools as needed.
I am keeping things simple by making sure that both old kexec-tools and
new kexec-tools can use crashkernel=xM and one does not have to choose
between two based on what kexec-tools version you are using.
Also keeping things simple by not trying to *impose* a new crashkernel=
syntax on existing crashkernel=xM users.
Hence extending the semantics of crashkernel=xM makes sense to me.
Thanks
Vivek
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
WARNING: multiple messages have this Message-ID (diff)
From: Vivek Goyal <vgoyal@redhat.com>
To: Yinghai Lu <yinghai@kernel.org>
Cc: WANG Chao <chaowang@redhat.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
Pekka Enberg <penberg@kernel.org>,
Jacob Shin <jacob.shin@amd.com>,
Andrew Morton <akpm@linux-foundation.org>,
"Eric W. Biederman" <ebiederm@xmission.com>,
"kexec@lists.infradead.org" <kexec@lists.infradead.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] x86, kdump: crashkernel=X try to reserve below 896M first, then try below 4G, then MAXMEM
Date: Thu, 24 Oct 2013 15:18:21 -0400 [thread overview]
Message-ID: <20131024191821.GE2322@redhat.com> (raw)
In-Reply-To: <CAE9FiQUu0WwMgNpog4TKch+MT2i7_DsNvqZxbyQusS4AFxdhQQ@mail.gmail.com>
On Thu, Oct 24, 2013 at 12:15:25PM -0700, Yinghai Lu wrote:
> On Thu, Oct 24, 2013 at 7:02 AM, Vivek Goyal <vgoyal@redhat.com> wrote:
> > On Wed, Oct 23, 2013 at 11:11:51PM -0700, Yinghai Lu wrote:
> >
> > 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.
>
> Make the thing simple.
> Keep them separately, leave crashkernel=xM to old kexec-tools mostly
> and keep crashkernel=xM,high to newer kexec-tools as needed.
I am keeping things simple by making sure that both old kexec-tools and
new kexec-tools can use crashkernel=xM and one does not have to choose
between two based on what kexec-tools version you are using.
Also keeping things simple by not trying to *impose* a new crashkernel=
syntax on existing crashkernel=xM users.
Hence extending the semantics of crashkernel=xM makes sense to me.
Thanks
Vivek
next prev parent reply other threads:[~2013-10-24 19:18 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-14 11:46 [PATCH] x86, kdump: crashkernel=X try to reserve below 896M first, then try below 4G, then MAXMEM WANG Chao
2013-10-14 11:46 ` WANG Chao
2013-10-14 18:54 ` Yinghai Lu
2013-10-14 18:54 ` Yinghai Lu
2013-10-15 3:00 ` WANG Chao
2013-10-15 3:00 ` WANG Chao
2013-10-15 14:48 ` Vivek Goyal
2013-10-15 14:48 ` Vivek Goyal
2013-10-18 3:50 ` Yinghai Lu
2013-10-18 3:50 ` Yinghai Lu
2013-10-18 12:38 ` Vivek Goyal
2013-10-18 12:38 ` Vivek Goyal
2013-10-19 5:45 ` Yinghai Lu
2013-10-19 5:45 ` Yinghai Lu
2013-10-21 15:16 ` Vivek Goyal
2013-10-21 15:16 ` Vivek Goyal
2013-10-24 6:11 ` Yinghai Lu
2013-10-24 6:11 ` Yinghai Lu
2013-10-24 11:01 ` WANG Chao
2013-10-24 11:01 ` WANG Chao
2013-10-24 19:13 ` Yinghai Lu
2013-10-24 19:13 ` Yinghai Lu
2013-10-24 19:24 ` Vivek Goyal
2013-10-24 19:24 ` Vivek Goyal
2013-10-24 14:02 ` Vivek Goyal
2013-10-24 14:02 ` Vivek Goyal
2013-10-24 19:15 ` Yinghai Lu
2013-10-24 19:15 ` Yinghai Lu
2013-10-24 19:18 ` Vivek Goyal [this message]
2013-10-24 19:18 ` Vivek Goyal
2013-10-24 19:24 ` Yinghai Lu
2013-10-24 19:24 ` Yinghai Lu
2013-10-24 19:27 ` Vivek Goyal
2013-10-24 19:27 ` Vivek Goyal
2013-10-24 19:37 ` Vivek Goyal
2013-10-24 19:37 ` Vivek Goyal
2013-10-25 5:48 ` Yinghai Lu
2013-10-25 5:48 ` Yinghai Lu
2013-10-28 5:49 ` Dave Young
2013-10-28 5:49 ` Dave Young
2013-10-28 5:51 ` Dave Young
2013-10-28 5:51 ` Dave Young
2013-10-28 15:12 ` Vivek Goyal
2013-10-28 15:12 ` Vivek Goyal
2013-11-04 14:38 ` WANG Chao
2013-11-04 14:38 ` WANG Chao
2013-10-28 5:47 ` Dave Young
2013-10-28 5:47 ` Dave Young
2013-10-24 19:04 ` Yinghai Lu
2013-10-24 19:04 ` Yinghai Lu
2013-10-28 6:43 ` WANG Chao
2013-10-28 6:43 ` WANG Chao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20131024191821.GE2322@redhat.com \
--to=vgoyal@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=chaowang@redhat.com \
--cc=ebiederm@xmission.com \
--cc=hpa@zytor.com \
--cc=jacob.shin@amd.com \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=penberg@kernel.org \
--cc=tglx@linutronix.de \
--cc=yinghai@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.