Re: [PATCH] [RFC][Patch x86-tip] add notifier before kdump

[Jin Dongming <jin.dongming@np.css.fujitsu.com>]

Hi Eric

Thanks for your comment.
I will consider the method you suggested. Thank you very much.

Best regards,
Jin Dongming

Eric W. Biederman wrote:
> 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
> --
> 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/
> 
>