watchdog机制
Posted 随风飘落的雨滴
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了watchdog机制相关的知识,希望对你有一定的参考价值。
转自:http://blog.sina.com.cn/s/blog_4dff871201012yzh.html
什么是Watchdog?
Watchdog,又称watchdog timer,是计算机可靠性(dependability)领域中一个极为简单同时非常有效的检测(detection)工具。其基本思想是针对被监视的目标设置一个计数器和一个阈值,watchdog会自己增加计数值,并等待被监视的目标周期性地重置计数值。一旦目标发生错误,没来得及重置计数值,watchdog会检测到计数值溢出,并采取恢复措施(通常情况下是重启)。总结一下就是计数——溢出——触发。
Watchdog的工作方式是事件触发的,它可以对任何合理的事件计数(如CPU指令)。其中时间事件(timeout)最常使用,这也是为什么watchdog又叫做watchdog timer。但无论watchdog统计什么事件,它的思想都是一样的。
归根结底,Watchdog是一种检测手段,它监视的目标可以是一个进程也可以是整个操作系统。Watchdog的合理性基于这样的假设:一个正常运行的系统,它的执行流应该是可预测的,因此可以在它正常执行路径上设置一些周期性重置watchdog的点;但如果系统发生故障,它可能执行不到下一个重置watchdog的点,此时故障将被watchdog捕捉到。看到这儿,您应该想到watchdog对于检测死循环或死锁这类故障非常有效。
Watchdog的实现
针对不同的监视目标,watchdog可以采取不同的实现方法。
- 监视一个进程
如果监视目标只是一个进程,那么利用操作系统提供的定时功能即可实现一个watchdog。
- 监视一个操作系统
如果要监视操作系统,就得使用操作系统之外的工具,通常是一个附加的计数器。现代Intel CPU都包含的performance counter也可以提供这样的功能,从而不需要额外的设备就能实现监视操作系统的watchdog。
关于操作系统watchdog的设计策略以及实现方法,可参考论文"Exploring Recovery from Operating System Lockups"。
Watchdog in Linux
Linux很早就引进了watchdog,事实上,Linux中有两套watchdog体系:
1) The Linux Watchdog driver API
2) NMI watchdog
第一种watchdog网上已经有很多很好的讲解资料,比如这篇《使用 watchdog 构建高可用性的 Linux 系统及应用》以及Linux的文档和man手册。 本文要详解的是第二种,即NMI Watchdog。
NMI watchdog in Linux
NMI watchdog是Linux的开发者为了debugging而添加的特性,但也能用来检测和恢复Linux kernel hang,现代多核x86体系都能支持NMI watchdog。NMI(Non Maskable Interrupt)即不可屏蔽中断,之所以要使用NMI,是因为NMI watchdog的监视目标是整个内核,而内核可能发生在关中断同时陷入死循环的错误,此时只有NMI能拯救它。
NMI watchdog的思想如前所述,仍然是通过计数和阈值进行监控。要打开NMI watchdog,只需要在grub.cfg中添加一句"nmi_watchdog=N",重启之后NMI watchdog就已经开启了。
Linux中有两种NMI watchdog,分别是I/O APIC watchdog(nmi_watchdog=1)和Local APIC watchdog(nmi_watchdog=2)。它们的触发机制不同,但触发NMI之后的操作是几乎一样的。从名字上看,它们都利用了APIC,所以前面强调这是被现代多核x86体系支持的功能。下面介绍这两种NMI watchdog的监测机制。
P.S. 我的Linux内核版本是2.6.32.21。
I/O APIC watchdog
如果已经熟悉了Intel APIC架构,那么再来了解Linux NMI watchdog就是易如反掌,相关资料可以先看看这篇《Linux内核中断内幕》热热身,然后看完最新的Intel® 64 and IA-32 Architectures Software Developer\'s Manual, Volume 3: System Programming Guide的第10章《Chapter 10 Advanced Programmable Interrupt Controller (APIC)》就够了,没有什么资料比Intel手册更详尽了。
I/O APIC watchdog的工作方式比较奇葩,一旦开启了I/O APIC watchdog(nmi_watchdog=1),那么每个CPU对应的Local APIC的LINT0线都关联到NMI,这样每个CPU将周期性地接到NMI(这个周期与Local timer的周期相同),接到中断的CPU立即处理NMI。处理的过程就是检查CPU的irq_stat(统计CPU中断信息的结构体,多核系统中这将是个数组)中的apic_timer_irqs和irq0_irqs这两个字段的和,它们分别代表了当前CPU从启动到现在处理的本地时钟中断次数和全局时钟中断次数。如果这两个值的和在一定时间(在我的机子上是5秒)之内都没有增加,说明这个CPU已经连续5秒没有处理过一次时钟中断,显然,出大事了。
arch/x86/kernel/traps.c: do_nmi, default_do_nmi
arch/x86/kernel/dumpstack.c: die_nmi
arch/x86/kernel/apic/nmi.c: nmi_watchdog_tick
Local APIC watchdog
想了解Local APIC watchdog也需要先看Intel手册……仍然是最新的Intel® 64 and IA-32 Architectures Software Developer\'s Manual, Volume 3: System Programming Guide,第18章《Chapter 18 Performance Monitoring》。这一章列出了Intel所有体系的PM,内容超多,但只要看
- 18.2.3 Pre-defined Architectural Performance Events
- 18.17 Performance Monitoring (P6 Family Processor)
- 18.18 Performance Monitoring (Pentium Processors)
这三部分就足矣。如果觉得Intel手册内容太多或者看英文比较吃力,可以参考张银奎老师的《软件调试》第5.5节,《性能监视》。
Intel CPU带有performance counter,可以对的许多事件计数(P4系列多达43到45个,具体数目视型号而定),在watchdog中,统计的事件是"UnHalted Core Cycle",即CPU处于非halt状态下经过的周期数。当计数溢出时,Local APIC会向CPU发出一个PMI(performance counter interrupt)。PMI的属性可选,理所应当的,在Local APIC watchdog中它被设置成NMI。利用这个特性,就能周期性地产生NMI。
发出NMI之后,Local APIC watchdog的行为就与I/O APIC watchdog几乎一样了,仍然是检查CPU处理时钟中断的次数。唯一的区别是,在处理NMI的过程中还多执行一项操作:重置performance counter。由于Local APIC watchdog统计的是UnHalted Cycles,所以系统空闲的时候,NMI触发的频率比较低。
arch/x86/perfctr_watchdog.c: lapic_wd_event
die_nmi
NMI watchdog在发现故障之后调用了die_nmi,我们来看看这个函数到底做了什么:
一个一个来解析:
- notify_die通知对NMI感兴趣、即订阅了die_chain的模块
- show_registers调用printk输出出当前寄存器信息,别忘了NMI watchdog本来是为了debugging哦
- 根据do_panic和panic_on_timeout的值决定是否要panic,do_panic是die_nmi的参数,panic_on_timeout是启动项参数,当然启动之后也可以通过/proc动态修改它的值
- do_exit就是恢复操作,Linux陷入hang,current进程有很大的嫌疑,所以退出当前进程有一定几率恢复系统运行。
对比两种NMI watchdog,其实各有长短。
I/O APIC watchdog的缺点很明显……每个时钟周期都要触发NMI,这对性能是个不小的影响,引用Linux Document的原话"...its NMI frequency is much higher, resulting in a more significant hit to the overall system performance",而且可靠性不太好。我开启watchdog之后,写了个关中断+死循环的kernel module并且加载到系统中,结果Linux跪了——这意味着I/O APIC watchdog没起作用。
Local APIC watchdog的触发频率要低一些,性能开销也要小一些。但是注意它统计的事件,"UnHalted Core Cycle",也就是说,万一CPU进入了关中断+halt的状态,那它也没救了,因为这时候计数器根本就不走了。但是I/O APIC watchdog却没有这个缺陷。但是就可靠性而言,Local APIC watchdog的表现更好,我开启它之后通过module注入了各种spinlock死锁,它居然都恢复了……
Postscript
以上关于两种NMI watchdog的说明,我已经省去了很多很多细节(=_=),尤其是初始化。I/O APIC watchdog的初始化细节在arch/x86/kernel/apic/apic.c;Local APIC watchdog的全部实现都在arch/x86/perfctr_watchdog.c。Local APIC watchdog的初始化看得我都要吐血了-.-
为了彻底了解Linux NMI watchdog的工作原理,我尝试了各种途径:
- BBS
- Stack Overflow
- Intel Manual
- Linux Document
- Source code
几乎是一切有效的信息源全部用上了,但这其中真正有用的只有Source code和E-mail。源代码就不说了,我原本只有两天时间来弄清楚NMI watchdog,大树又多给我加了3天时间之后,立即决定啃源码。所幸NMI watchdog涉及到的代码总共也只有数千行,并且代码逻辑并不复杂。
另一方面,我查询了watchdog相关的邮件列表,并给相关的开发者发了邮件,只有一位Redhat的工程师Don Zickus回复了我,他的回信给了我非常大的帮助。不过他提到"ah, 2.6.32, uses the old nmi_watchdog"……old nmi_watchdog!我在另一台内核版本为3.0.3的机器上打开了NMI watchdog,发现它们都没有起作用-_-
即便我看遍了代码,还是有两个问题始终没有找到答案:
一、APIC_LVT0是怎么跟APIC_LVTT接上的,如何向所有CPU发NMI??
二、ESCR_MSR和CCCR_MSR的初始化参数到底是什么意思!!?
本次斗狗经历让我收获了许多:
一、对Intel中断体系有了更深入的了解
二、第一次在没有直接指导的情况下啃kernel code
三、一次不同寻常的学习经历,反复列出疑点解决问题
四、Source Insight真乃神器也!
五、原来在Stack Overflow上问问题也有没有人回的时候!
以下转自:http://www.cnblogs.com/sdphome/archive/2011/11/16/2251042.html
NMI Watchdog Timer
以上是关于watchdog机制的主要内容,如果未能解决你的问题,请参考以下文章
Android 进阶——SystemServer进程启动之Watchdog 详解
Android 进阶——系统启动之SystemServer进程创建并启动Watchdog 监听系统服务详解
Android 进阶——系统启动之SystemServer进程创建并启动Watchdog 监听系统服务详解