什么是Watchdog?

什么是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 watchdogLinux的开发者为了debugging而添加的特性,但也能用来检测和恢复Linux kernel hang现代多核x86体系都能支持NMI watchdogNMINon Maskable Interrupt)即不可屏蔽中断,之所以要使用NMI,是因为NMI watchdog的监视目标是整个内核,而内核可能发生在关中断同时陷入死循环的错误,此时只有NMI能拯救它。

NMI watchdog的思想如前所述,仍然是通过计数和阈值进行监控。要打开NMI watchdog,只需要在grub.cfg中添加一句"nmi_watchdog=N",重启之后NMI watchdog就已经开启了。

Linux中有两种NMI watchdog,分别是I/O APIC watchdognmi_watchdog=1)和Local APIC watchdognmi_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 watchdognmi_watchdog=1),那么每个CPU对应的Local APICLINT0线都关联到NMI,这样每个CPU将周期性地接到NMI(这个周期与Local timer的周期相同),接到中断的CPU立即处理NMI。处理的过程就是检查CPUirq_stat(统计CPU中断信息的结构体,多核系统中这将是个数组)中的apic_timer_irqsirq0_irqs这两个字段的和,它们分别代表了当前CPU从启动到现在处理的本地时钟中断次数和全局时钟中断次数。如果这两个值的和在一定时间(在我的机子上是5秒)之内都没有增加,说明这个CPU已经连续5秒没有处理过一次时钟中断,显然,出大事了。

Watchdog, <wbr>watchdog <wbr>in <wbr>Linux

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系列多达4345个,具体数目视型号而定),在watchdog中,统计的事件是"UnHalted Core Cycle",即CPU处于非halt状态下经过的周期数。当计数溢出时,Local APIC会向CPU发出一个PMIperformance 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触发的频率比较低。

Watchdog, <wbr>watchdog <wbr>in <wbr>Linux

arch/x86/perfctr_watchdog.c: lapic_wd_event

 

 

die_nmi

NMI watchdog在发现故障之后调用了die_nmi,我们来看看这个函数到底做了什么:

Watchdog, <wbr>watchdog <wbr>in <wbr>Linux

一个一个来解析:

  • notify_die通知对NMI感兴趣即订阅了die_chain的模块
  • show_registers调用printk输出出当前寄存器信息,别忘了NMI watchdog本来是为了debugging
  • 根据do_panicpanic_on_timeout的值决定是否要panicdo_panicdie_nmi的参数,panic_on_timeout是启动项参数,当然启动之后也可以通过/proc动态修改它的值
  • do_exit就是恢复操作,Linux陷入hangcurrent进程有很大的嫌疑,所以退出当前进程有一定几率恢复系统运行。

 

对比两种NMI watchdog,其实各有长短。

I/O APIC watchdog的缺点很明显……每个时钟周期都要触发NMI,这对性能是个不小的影响,引用Linux Document的原话"...its NMI frequency is much higher, resulting in 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.cLocal APIC watchdog的全部实现都在arch/x86/perfctr_watchdog.cLocal APIC watchdog的初始化看得我都要吐血了-.-

为了彻底了解Linux NMI watchdog的工作原理,我尝试了各种途径:

  • Google
  • BBS
  • Stack Overflow
  • Intel Manual
  • Linux Document
  • E-mail
  • Source code

几乎是一切有效的信息源全部用上了,但这其中真正有用的只有Source codeE-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接上的,如何向所有CPUNMI??

二、ESCR_MSRCCCR_MSR的初始化参数到底是什么意思!!?

 

本次斗狗经历让我收获了许多:

一、Intel中断体系有了更深入的了解

二、第一次在没有直接指导的情况下啃kernel code

三、一次不同寻常的学习经历,反复列出疑点解决问题

四、Source Insight真乃神器也!

五、原来在Stack Overflow上问问题也有没有人回的时候


  • 7
    点赞
  • 24
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值