From: Vivek Goyal <vgoyal@redhat.com>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Yinghai Lu <yinghai@kernel.org>, Ingo Molnar <mingo@kernel.org>,
jerry.hoemann@hp.com, Pekka Enberg <penberg@kernel.org>,
Rob Landley <rob@landley.net>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, x86 maintainers <x86@kernel.org>,
Matt Fleming <matt.fleming@intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
"list@ebiederm.org:DOCUMENTATION" <linux-doc@vger.kernel.org>,
"list@ebiederm.org:MEMORY MANAGEMENT" <linux-mm@kvack.org>,
linux-efi@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/3] Early use of boot service memory
Date: Mon, 18 Nov 2013 10:22:55 -0500 [thread overview]
Message-ID: <20131118152255.GA32168@redhat.com> (raw)
In-Reply-To: <52867309.4040406@zytor.com>
On Fri, Nov 15, 2013 at 11:16:25AM -0800, H. Peter Anvin wrote:
> On 11/15/2013 10:46 AM, H. Peter Anvin wrote:
> > On 11/15/2013 10:30 AM, Vivek Goyal wrote:
> >>
> >> I agree taking assistance of hypervisor should be useful.
> >>
> >> One reason we use kdump for VM too because it makes life simple. There
> >> is no difference in how we configure, start and manage crash dumps
> >> in baremetal or inside VM. And in practice have not heard of lot of
> >> failures of kdump in VM environment.
> >>
> >> So while reliability remains a theoritical concern, in practice it
> >> has not been a real concern and that's one reason I think we have
> >> not seen a major push for alternative method in VM environment.
> >>
> >
> > Another reason, again, is that it doesn't sit on all that memory.
> >
>
> This led me to a potentially interesting idea. If we can tell the
> hypervisor about which memory blocks belong to kdump, we can still use
> kdump in its current form with only a few hypervisor calls thrown in.
>
> One set of calls would mark memory ranges as belonging to kdump. This
> would (a) make them protected,
This sounds good. We already have arch hooks to map/unmap crash kernel
ranges, crash_map_reserved_pages() and crash_unmap_reserved_pages(). Now x86,
should be able to use these hooks to tell hypervisor to remove mappings
for certain physical certain ranges and remap these back when needed. s390
already does some magic there.
> and (b) tell the hypervisor that these
> memory ranges will not be accessed and don't need to occupy physical RAM.
I am not sure if we need to do anything here. I am assuming that most of
the crashkernel memory has not been touched and does not occupy physical
memory till crash actually happens. We probably will touch only 20-30MB
of crashkernel memory during kernel load and that should ultimately make
its way to swap at some point of time.
And if that's true, then reserving 72M extra due to crashkernel=X,high
should not be a big issue in KVM guests. It will still be an issue on
physical servers though.
Thanks
Vivek
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2013-11-18 15:23 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1384222558-38527-1-git-send-email-jerry.hoemann@hp.com>
[not found] ` <d73ccce9-6a0d-4470-bda3-f0c6eb96b5e4@email.android.com>
[not found] ` <20131113224503.GB25344@anatevka.fc.hp.com>
[not found] ` <52840206.5020006@zytor.com>
[not found] ` <20131113235708.GC25344@anatevka.fc.hp.com>
[not found] ` <CAOJsxLFkHQ6_f+=CMwfNLykh59TZH5VrWeVEDPCWPF1wiw7tjQ@mail.gmail.com>
[not found] ` <20131114180455.GA32212@anatevka.fc.hp.com>
[not found] ` <CAOJsxLFWMi8DoFp+ufri7XoFO27v+2=0oksh8+NhM6P-OdkOwg@mail.gmail.com>
2013-11-14 18:45 ` [PATCH 0/3] Early use of boot service memory H. Peter Anvin
[not found] ` <20131115005049.GJ5116@anatevka.fc.hp.com>
[not found] ` <20131115062417.GB9237@gmail.com>
[not found] ` <CAE9FiQWzSTtW8N=0hoUe6iCSM-k64Mv97n0whAS0_vZ+psuOsg@mail.gmail.com>
2013-11-15 6:59 ` H. Peter Anvin
2013-11-15 14:07 ` Vivek Goyal
2013-11-15 17:33 ` Yinghai Lu
2013-11-15 17:40 ` H. Peter Anvin
2013-11-15 18:30 ` Vivek Goyal
2013-11-15 18:46 ` H. Peter Anvin
2013-11-15 19:16 ` H. Peter Anvin
2013-11-18 15:22 ` Vivek Goyal [this message]
2013-11-18 18:29 ` H. Peter Anvin
2013-11-18 18:52 ` Vivek Goyal
2013-11-19 1:32 ` H. Peter Anvin
2013-11-19 3:02 ` Yinghai Lu
2013-11-15 18:03 ` Vivek Goyal
2013-11-15 22:24 ` Yinghai Lu
2013-11-15 22:55 ` jerry.hoemann
2013-11-15 23:43 ` Yinghai Lu
2013-11-18 15:32 ` Vivek Goyal
2013-11-18 19:34 ` Yinghai Lu
2013-11-18 19:39 ` Vivek Goyal
2013-11-15 18:16 ` jerry.hoemann
2013-11-15 8:36 ` Pekka Enberg
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=20131118152255.GA32168@redhat.com \
--to=vgoyal@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=hpa@zytor.com \
--cc=jerry.hoemann@hp.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=matt.fleming@intel.com \
--cc=mingo@kernel.org \
--cc=mingo@redhat.com \
--cc=penberg@kernel.org \
--cc=rob@landley.net \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
--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;
as well as URLs for NNTP newsgroup(s).