lkml.org 
[lkml]   [2013]   [Oct]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] x86, kdump: crashkernel=X try to reserve below 896M first, then try below 4G, then MAXMEM
On Mon, Oct 14, 2013 at 11:54:22AM -0700, 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.
> >
> > So that user can easily reserve large memory with crashkernel=X instead
> > of crashkernel=X,high. It's more transparent and user-friendly.
> >
> > If crashkernel is large and the reserved is beyond 896M, old kexec-tools
> > won't be compatible with new kernel for most of time.
> >
> > kexec will fail out immediately in this case. But the failure could be
> > expected, because old kexec users should not try to reserve that large
> > amount of memory at the first place.
> >
> > On the other hand, old kexec also will fail on old kernel when there's
> > not enough low memory to reserve a large crash kernel area. So the
> > failure of old kexec is consistent between old kernel and new kernel.
> >
> > Signed-off-by: WANG Chao <chaowang@redhat.com>
> > ---
> > arch/x86/kernel/setup.c | 14 ++++++++++++++
> > 1 file changed, 14 insertions(+)
> >
> > 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);
> > + /*
> > + * 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");
> > --
>
> User should change crashkernel=X to crashkernel=X,high.

I think if we can extend old syntax of crashkernel=X, then it makes life
really easy for users.

>
> As user could forget to update kexec-tools to utilize ",high" feature, and get
> kdump later fail later.

Previously high reservation (reservation above 896M) will anyway fail. So
instead of failing, if we try reservation in higher memory areas why that
would break old kexec-tools?

IOW, previously anyway kexec-tools will not work as no memory will be
reserved in higher memory area. Now memory will be reserved but old
kexec-tools should fail as it can't load in that area.

If that works, then one would use crashkernel=X,high only if he is
particualr that memory reservation comes from area above 4G (despite
the fact that same memory could have been reserved below 4G too).

Thanks
Vivek


\
 
 \ /
  Last update: 2013-10-15 20:21    [W:0.164 / U:0.308 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site