Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753493AbZJ2FcE (ORCPT ); Thu, 29 Oct 2009 01:32:04 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753098AbZJ2FcD (ORCPT ); Thu, 29 Oct 2009 01:32:03 -0400 Received: from out01.mta.xmission.com ([166.70.13.231]:37271 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751798AbZJ2FcB (ORCPT ); Thu, 29 Oct 2009 01:32:01 -0400 To: Jin Dongming Cc: Lon Hohberger , Vivek Goyal , LKLM , Kenji Kaneshige , Hidetoshi Seto , Neil Horman Subject: Re: [PATCH] [RFC][Patch x86-tip] add notifier before kdump References: <4AE6B1CC.6040603@np.css.fujitsu.com> <20091027150725.GD10513@redhat.com> <1256660208.15137.102.camel@localhost.localdomain> <4AE91645.8080903@np.css.fujitsu.com> From: ebiederm@xmission.com (Eric W. Biederman) Date: Wed, 28 Oct 2009 22:32:04 -0700 In-Reply-To: <4AE91645.8080903@np.css.fujitsu.com> (Jin Dongming's message of "Thu\, 29 Oct 2009 13\:12\:53 +0900") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-XM-SPF: eid=;;;mid=;;;hst=in01.mta.xmission.com;;;ip=76.21.114.89;;;frm=ebiederm@xmission.com;;;spf=neutral X-SA-Exim-Connect-IP: 76.21.114.89 X-SA-Exim-Mail-From: ebiederm@xmission.com X-SA-Exim-Version: 4.2.1 (built Thu, 25 Oct 2007 00:26:12 +0000) X-SA-Exim-Scanned: No (on in01.mta.xmission.com); Unknown failure Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2265 Lines: 46 Jin Dongming 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/