什么是Watchdog？

Watchdog，又称watchdog timer，是计算机可靠性（dependability）领域中一个极为简单同时非常有效的检测（detection）工具。其基本思想是针对被监视的目标设置一个计数器和一个阈值，watchdog会自己增加计数值，并等待被监视的目标周期性地重置计数值。一旦目标发生错误，没来得及重置计数值，watchdog会检测到计数值溢出，并采取恢复措施（通常情况下是重启）。总结一下就是计数——溢出——触发。
Watchdog的工作方式是事件触发的，它可以对任何合理的事件计数（如CPU指令）。其中时间事件（timeout）最常使用，这也是为什么watchdog又叫做watchdog timer。但无论watchdog统计什么事件，它的思想都是一样的。
归根结底，Watchdog是一种检测手段，它监视的目标可以是一个进程也可以是整个操作系统。Watchdog的合理性基于这样的假设：一个正常运行的系统，它的执行流应该是可预测的，因此可以在它正常执行路径上设置一些周期性重置watchdog的点；但如果系统发生故障，它可能执行不到下一个重置watchdog的点，此时故障将被watchdog捕捉到。看到这儿，您应该想到watchdog对于检测死循环或死锁这类故障非常有效。

Watchdog的实现

针对不同的监视目标，watchdog可以采取不同的实现方法。
1) 监视一个进程
如果监视目标只是一个进程，那么利用操作系统提供的定时功能即可实现一个watchdog。

2) 监视一个操作系统

如果要监视操作系统，就得使用操作系统之外的工具，通常是一个附加的计数器。现代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的工作原理，我尝试了各种途径：

Google
BBS
Stack Overflow
Intel Manual
Linux Document
E-mail
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上问问题也有没有人回的时候