public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Jin Dongming <jin.dongming@np.css.fujitsu.com>
Cc: Lon Hohberger <lhh@redhat.com>, Vivek Goyal <vgoyal@redhat.com>,
	LKLM <linux-kernel@vger.kernel.org>,
	Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>,
	Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>,
	Neil Horman <nhorman@redhat.com>
Subject: Re: [PATCH] [RFC][Patch x86-tip] add notifier before kdump
Date: Wed, 28 Oct 2009 22:32:04 -0700	[thread overview]
Message-ID: <m1fx927okr.fsf@fess.ebiederm.org> (raw)
In-Reply-To: <4AE91645.8080903@np.css.fujitsu.com> (Jin Dongming's message of "Thu\, 29 Oct 2009 13\:12\:53 +0900")

Jin Dongming <jin.dongming@np.css.fujitsu.com> writes:

> Vivek, Lon Hohberger
>
> Thanks for your comments.
>
> I also agree with your opinion, too. But I still have problems listed
> as following.
>     1. Nobody knows when the second kernel does not work well
>     2. Too much time cost to startup the second kernel
>
> So I hope that following work could be done. 
>     1. Add some code before kdump to monitor the actions of second kernel
>        Something we worried about is that nobody knows when the kdump will not
>        work well. If the second kernel does not work well, nobody knows when
>        the best time is to restart. So we need to add some code such as setting
>        watchdog. If we want to monitor second kernel, some work need to be done
>        before it starts to work.

Any extra work done in the crashing kernel decreases the likely hood
of the second kernel working.  If you want a watchdog I recommend you always
run it and have the interval set large enough for the second kernel to boot
before it starts petting it.  That way no code needs to run after a kernel crash.

>     2. Shorten the startup time of second kernel
>        I think that the purpose of second kernel is used for backup information
>        stored in memory to storage only. But the time cost is different
>        according to the system architecture. And also I think that there are
>        too many of device is not useful to get the memory information to
>        storage. I think the startup time of second kernel should be shortened.
>        I don't know much about second kernel, these are only my thought.

The second kernel can be anything you like.  Including a standalone executable
if needed for very precise requirements.  Any improvements in boot time for a
normal linux image should apply to the dump kernel.

Currently with a tight initrd and just dumping dmesg to disk I get away with
a 20M crashkernel reservation, and it typically runs and does it's work before
my watchdog fires.

Eric

  reply	other threads:[~2009-10-29  5:32 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-27  8:39 [PATCH] [RFC][Patch x86-tip] add notifier before kdump Jin Dongming
2009-10-27 15:07 ` Vivek Goyal
2009-10-27 16:16   ` Lon Hohberger
2009-10-29  4:12     ` Jin Dongming
2009-10-29  5:32       ` Eric W. Biederman [this message]
2009-10-29  7:48         ` Jin Dongming
2009-10-29  7:52   ` Jin Dongming
2009-10-29 18:43     ` Eric W. Biederman

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=m1fx927okr.fsf@fess.ebiederm.org \
    --to=ebiederm@xmission.com \
    --cc=jin.dongming@np.css.fujitsu.com \
    --cc=kaneshige.kenji@jp.fujitsu.com \
    --cc=lhh@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nhorman@redhat.com \
    --cc=seto.hidetoshi@jp.fujitsu.com \
    --cc=vgoyal@redhat.com \
    /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