From: Vivek Goyal <vgoyal@redhat.com> To: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com> Cc: linux-kernel@vger.kernel.org, kexec@lists.infradead.org, x86@kernel.org, mingo@elte.hu, tglx@linutronix.de, hpa@zytor.com, len.brown@intel.com, fenghua.yu@intel.com, ebiederm@xmission.com, grant.likely@secretlab.ca, rob.herring@calxeda.com, Michael Holzheu <holzheu@linux.vnet.ibm.com> Subject: Re: [PATCH v1 0/2] x86, apic: Disable BSP if boot cpu is AP Date: Fri, 19 Oct 2012 11:17:53 -0400 [thread overview] Message-ID: <20121019151753.GF27052@redhat.com> (raw) In-Reply-To: <20121019.122054.476812873.d.hatayama@jp.fujitsu.com> On Fri, Oct 19, 2012 at 12:20:54PM +0900, HATAYAMA Daisuke wrote: [..] > > Instead of capturing the dump of whole memory, isn't it more efficient > > to capture the crash dump of VM in question and then if need be just > > take filtered crash dump of host kernel. > > > > I think that trying to take unfiltered crash dumps of tera bytes of memory > > is not practical or woth it for most of the use cases. > > > > If there's a lag between VM dump and host dump, situation on the host > can change, and VM dump itself changes the situation. Then, we cannot > know what kind of bug resides in now, so we want to do as few things > as possible between detecting the bug reproduced and taking host > dump. So I expressed ``capturing the situation''. I would rather first detect the problem on guest and figure out what's happening. Once it has been determined that something is wrong from host side then debug what's wrong with host by using regular kernel debugging techiniques. Even if you are interested in capturing crash dump, after you have decided that it is a host problem, then you can write some scripts which trigger host crash dump when relevant event happens. Seriously, this argument could be extended to regular processes also. Something is wrong with my application, so lets dump the whole system, provide a facility to extract each process's code dump from that huge dump and then examine if it was an application issue or kernel issue. I am skeptical that this approach is going to fly in practice. Dumping huge images, processing and transferring these is not very practical. So I would rather narrow down the problem on a running system and take filtered dump of appropriate component where I suspect the problem is. [..] > > capability was the primary reason that s390 also wants to support > > kdump otherwise there firmware dumping mechanism was working just > > fine. > > > > I don't know s390 firmware dumping mechanism at all, but is it possble > for s390 to filter crash dump even on firmware dumping mechanism? AFAIK, s390 dump mechanism could not filter dump and tha's the reason they wanted to support kdump and /proc/vmcore so that makedumpfile could filter it. I am CCing Michael Holzheu, who did the s390 kdump work. He can tell it better. Thanks Vivek
WARNING: multiple messages have this Message-ID (diff)
From: Vivek Goyal <vgoyal@redhat.com> To: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com> Cc: len.brown@intel.com, fenghua.yu@intel.com, x86@kernel.org, kexec@lists.infradead.org, linux-kernel@vger.kernel.org, rob.herring@calxeda.com, grant.likely@secretlab.ca, ebiederm@xmission.com, hpa@zytor.com, mingo@elte.hu, Michael Holzheu <holzheu@linux.vnet.ibm.com>, tglx@linutronix.de Subject: Re: [PATCH v1 0/2] x86, apic: Disable BSP if boot cpu is AP Date: Fri, 19 Oct 2012 11:17:53 -0400 [thread overview] Message-ID: <20121019151753.GF27052@redhat.com> (raw) In-Reply-To: <20121019.122054.476812873.d.hatayama@jp.fujitsu.com> On Fri, Oct 19, 2012 at 12:20:54PM +0900, HATAYAMA Daisuke wrote: [..] > > Instead of capturing the dump of whole memory, isn't it more efficient > > to capture the crash dump of VM in question and then if need be just > > take filtered crash dump of host kernel. > > > > I think that trying to take unfiltered crash dumps of tera bytes of memory > > is not practical or woth it for most of the use cases. > > > > If there's a lag between VM dump and host dump, situation on the host > can change, and VM dump itself changes the situation. Then, we cannot > know what kind of bug resides in now, so we want to do as few things > as possible between detecting the bug reproduced and taking host > dump. So I expressed ``capturing the situation''. I would rather first detect the problem on guest and figure out what's happening. Once it has been determined that something is wrong from host side then debug what's wrong with host by using regular kernel debugging techiniques. Even if you are interested in capturing crash dump, after you have decided that it is a host problem, then you can write some scripts which trigger host crash dump when relevant event happens. Seriously, this argument could be extended to regular processes also. Something is wrong with my application, so lets dump the whole system, provide a facility to extract each process's code dump from that huge dump and then examine if it was an application issue or kernel issue. I am skeptical that this approach is going to fly in practice. Dumping huge images, processing and transferring these is not very practical. So I would rather narrow down the problem on a running system and take filtered dump of appropriate component where I suspect the problem is. [..] > > capability was the primary reason that s390 also wants to support > > kdump otherwise there firmware dumping mechanism was working just > > fine. > > > > I don't know s390 firmware dumping mechanism at all, but is it possble > for s390 to filter crash dump even on firmware dumping mechanism? AFAIK, s390 dump mechanism could not filter dump and tha's the reason they wanted to support kdump and /proc/vmcore so that makedumpfile could filter it. I am CCing Michael Holzheu, who did the s390 kdump work. He can tell it better. Thanks Vivek _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2012-10-19 15:18 UTC|newest] Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-10-16 4:35 [PATCH v1 0/2] x86, apic: Disable BSP if boot cpu is AP HATAYAMA Daisuke 2012-10-16 4:35 ` HATAYAMA Daisuke 2012-10-16 4:35 ` [PATCH v1 1/2] x86, apic: Introduce boot_cpu_is_bsp indicating whether boot cpu is BSP or not HATAYAMA Daisuke 2012-10-16 4:35 ` HATAYAMA Daisuke 2012-10-16 4:35 ` [PATCH v1 2/2] x86, apic: Disable BSP if boot cpu is AP HATAYAMA Daisuke 2012-10-16 4:35 ` HATAYAMA Daisuke 2012-10-22 20:04 ` Eric W. Biederman 2012-10-22 20:04 ` Eric W. Biederman 2012-10-22 20:16 ` H. Peter Anvin 2012-10-22 20:16 ` H. Peter Anvin 2012-10-22 20:31 ` Eric W. Biederman 2012-10-22 20:31 ` Eric W. Biederman 2012-10-22 20:33 ` H. Peter Anvin 2012-10-22 20:33 ` H. Peter Anvin 2012-10-22 20:38 ` H. Peter Anvin 2012-10-22 20:38 ` H. Peter Anvin 2012-10-22 20:43 ` Eric W. Biederman 2012-10-22 20:43 ` Eric W. Biederman 2012-10-22 20:47 ` H. Peter Anvin 2012-10-22 20:47 ` H. Peter Anvin 2012-10-22 21:29 ` Eric W. Biederman 2012-10-22 21:29 ` Eric W. Biederman 2012-10-23 0:35 ` H. Peter Anvin 2012-10-23 0:35 ` H. Peter Anvin 2012-10-26 3:24 ` HATAYAMA Daisuke 2012-10-26 3:24 ` HATAYAMA Daisuke 2012-10-26 4:13 ` Eric W. Biederman 2012-10-26 4:13 ` Eric W. Biederman 2013-03-11 1:07 ` HATAYAMA Daisuke 2013-03-11 1:07 ` HATAYAMA Daisuke 2013-03-11 2:13 ` HATAYAMA Daisuke 2013-03-11 2:13 ` HATAYAMA Daisuke 2013-03-11 4:11 ` H. Peter Anvin 2013-03-11 4:11 ` H. Peter Anvin 2012-10-16 4:51 ` [PATCH v1 0/2] " Yu, Fenghua 2012-10-16 4:51 ` Yu, Fenghua 2012-10-16 5:03 ` HATAYAMA Daisuke 2012-10-16 5:03 ` HATAYAMA Daisuke 2012-10-16 5:14 ` Yu, Fenghua 2012-10-16 5:14 ` Yu, Fenghua 2012-10-16 6:38 ` HATAYAMA Daisuke 2012-10-16 6:38 ` HATAYAMA Daisuke 2012-10-22 16:02 ` H. Peter Anvin 2012-10-22 16:02 ` H. Peter Anvin 2012-10-16 5:15 ` HATAYAMA Daisuke 2012-10-16 5:15 ` HATAYAMA Daisuke 2012-10-17 14:12 ` Vivek Goyal 2012-10-17 14:12 ` Vivek Goyal 2012-10-18 3:08 ` HATAYAMA Daisuke 2012-10-18 3:08 ` HATAYAMA Daisuke 2012-10-18 14:14 ` Vivek Goyal 2012-10-18 14:14 ` Vivek Goyal 2012-10-19 3:20 ` HATAYAMA Daisuke 2012-10-19 3:20 ` HATAYAMA Daisuke 2012-10-19 15:17 ` Vivek Goyal [this message] 2012-10-19 15:17 ` Vivek Goyal 2012-10-22 6:32 ` HATAYAMA Daisuke 2012-10-22 6:32 ` HATAYAMA Daisuke 2012-10-22 18:37 ` Vivek Goyal 2012-10-22 18:37 ` Vivek Goyal 2012-10-22 17:10 ` Michael Holzheu 2012-10-22 17:10 ` Michael Holzheu
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=20121019151753.GF27052@redhat.com \ --to=vgoyal@redhat.com \ --cc=d.hatayama@jp.fujitsu.com \ --cc=ebiederm@xmission.com \ --cc=fenghua.yu@intel.com \ --cc=grant.likely@secretlab.ca \ --cc=holzheu@linux.vnet.ibm.com \ --cc=hpa@zytor.com \ --cc=kexec@lists.infradead.org \ --cc=len.brown@intel.com \ --cc=linux-kernel@vger.kernel.org \ --cc=mingo@elte.hu \ --cc=rob.herring@calxeda.com \ --cc=tglx@linutronix.de \ --cc=x86@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: linkBe 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.