Kexec Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: WANG Chao <chaowang@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>,
	Vivek Goyal <vgoyal@redhat.com>
Subject: Re: [PATCH] x86, kdump: crashkernel=X try to reserve below 896M first, then try below 4G, then MAXMEM
Date: Mon, 28 Oct 2013 14:43:15 +0800	[thread overview]
Message-ID: <20131028064315.GC3033@dhcp16-109.nay.redhat.com> (raw)
In-Reply-To: <CAE9FiQWC43b9ptv3=9cth_cPWYaCZ8aCuTdO5is_ESpiFajQTw@mail.gmail.com>

On 10/24/13 at 12:04pm, Yinghai Lu wrote:
> On Mon, Oct 14, 2013 at 4:46 AM, WANG Chao <chaowang@redhat.com> wrote:
> > Now crashkernel=X will fail out if there's not enough memory at
> > low (below 896M). What makes sense for crashkernel=X would be:
> >
> >  - First try to reserve X below 896M (for being compatible with old
> >    kexec-tools).
> >  - If fails, try to reserve X below 4G (swiotlb need to stay below 4G).
> >  - If fails, try to reserve X from MAXMEM top down.
> >
> > diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> > index f0de629..38e6c1f 100644
> > --- a/arch/x86/kernel/setup.c
> > +++ b/arch/x86/kernel/setup.c
> > @@ -593,6 +593,20 @@ static void __init reserve_crashkernel(void)
> >                                         high ? CRASH_KERNEL_ADDR_HIGH_MAX :
> >                                                CRASH_KERNEL_ADDR_LOW_MAX,
> >                                         crash_size, alignment);
> > +               /*
> > +                * crashkernel=X reserve below 896M fails? Try below 4G
> > +                */
> > +               if (!high && !crash_base)
> > +                       crash_base = memblock_find_in_range(alignment,
> > +                                               (1ULL << 32),
> > +                                               crash_size, alignment);
> 
> Another problem, it would allocate range in [0,4g) for 32bit,
> if the user have crashkernel=512M or plus.

Yes, should use #ifdef CONFIG_X86_64 .. #endif.
Thanks for pointing this out.

WANG Chao

> 
> > +               /*
> > +                * crashkernel=X reserve below 4G fails? Try MAXMEM
> > +                */
> > +               if (!high && !crash_base)
> > +                       crash_base = memblock_find_in_range(alignment,
> > +                                               CRASH_KERNEL_ADDR_HIGH_MAX,
> > +                                               crash_size, alignment);
> >
> >                 if (!crash_base) {
> >                         pr_info("crashkernel reservation failed - No suitable area found.\n");
> 
> 
> Yinghai

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

      reply	other threads:[~2013-10-28  6:43 UTC|newest]

Thread overview: 26+ 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 18:54 ` Yinghai Lu
2013-10-15  3:00   ` WANG Chao
2013-10-15 14:48   ` Vivek Goyal
2013-10-18  3:50     ` Yinghai Lu
2013-10-18 12:38       ` Vivek Goyal
2013-10-19  5:45         ` Yinghai Lu
2013-10-21 15:16           ` Vivek Goyal
2013-10-24  6:11             ` Yinghai Lu
2013-10-24 11:01               ` WANG Chao
2013-10-24 19:13                 ` Yinghai Lu
2013-10-24 19:24                   ` Vivek Goyal
2013-10-24 14:02               ` Vivek Goyal
2013-10-24 19:15                 ` Yinghai Lu
2013-10-24 19:18                   ` Vivek Goyal
2013-10-24 19:24                     ` Yinghai Lu
2013-10-24 19:27                       ` Vivek Goyal
2013-10-24 19:37                         ` Vivek Goyal
2013-10-25  5:48                         ` Yinghai Lu
2013-10-28  5:49                           ` Dave Young
2013-10-28  5:51                             ` Dave Young
2013-10-28 15:12                           ` Vivek Goyal
2013-11-04 14:38                             ` WANG Chao
2013-10-28  5:47               ` Dave Young
2013-10-24 19:04 ` Yinghai Lu
2013-10-28  6:43   ` WANG Chao [this message]

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=20131028064315.GC3033@dhcp16-109.nay.redhat.com \
    --to=chaowang@redhat.com \
    --cc=akpm@linux-foundation.org \
    --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=vgoyal@redhat.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox