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 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 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 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 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 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上问问题也有没有人回的时候!

 

 

 

以下转自:http://www.cnblogs.com/sdphome/archive/2011/11/16/2251042.html

 

NMI Watchdog Timer

1. 没有完美的代码
 
没有完美的人,更没有完美的代码。虽然教科书上说deadlock(死锁)多么不好不好,但是在现实生活中,很难把它完全消灭。假 设不小心内核出现了deadlock,可能你得干瞪眼。CPU就在那里空等着,空转着,叫天天不应,叫地地不灵。等到海枯石烂,CPU生锈的那一天,它还 会那么痴痴地等着那个霸占了锁的家伙会良心发现,解下这个锁。也许你会说,哎呀,这么麻烦干嘛?RESET一下,不就一了百了吗?但是如果是一台肩负重担 的Server(服务器),在夜深人静你正呼呼大睡的时候发生了deadlock呢?如果deadlock的原因没有查到,三天五天就会发生一次,光这样 被动的重启也不是办法……
 
不用说让人心惊胆颤的deadlock,很多时候,一段小小的循环,就会把你彻底雷到。我们总认为循环是可以结束的,但是别要忘 记,事物都是辩证的,有的时候,碰巧发生了某些预料之外的条件,让这个循环成了彻彻底底的死循环。恰巧此时,CPU的中断如果已经被禁掉,那神仙也救不了 你。“我佛慈悲,能不能把循环给我停掉?”“阿弥陀佛,神仙也得遵守潜规则,你让我给你停掉循环,好歹也要给我一个中断,让我能够施法吧?”……不能怪父 母,更不能怪政府,如果你正好在电脑旁边,可以RESET;如果你不在旁边,就等着老板的电话吧。“小福啊,今天又超过100位客户打电话投诉我们的交友 网站不能访问了,你赶紧打的到公司,看看是怎么回事。赶紧啊!有个客户说,如果今晚12点之前不能登录网站,取得要约会的5位MM的详细资料,他就会携带 人体炸弹到办公楼来砸场子……“
 
2. 保留现场,强行重启
 
言归正传。如果应用程序进入死循环,我们可以把它KILL掉。如果内核因为意料之外的原因,导致系统进入无法自拔的死循环,最好的 办法就是让系统给强行重启。当然,这种重启最好是自动的,不需要人干预的,且最好能够打印出导致重启的原因,便于开发者调试错误。在Linux内核中,用 NMI看门狗(NMI Watchdog Timer)的方式来实现该机制。
 
在系统的正常运行过程当中,每秒都有非常多的中断产生。即便它啥都不做,啥外部中断都不接收,每秒至少有数以百计的用来给线程调度的时钟中断。(如果调度时间片为10ms,则有100个时钟中断。)假设如果内核发现5秒钟之内,没有产生一个中断,那将会是怎么一回事呢?
 
这个时候,CPU会辩解道:“我兢兢业业地执行每一条指令,有没有中断不干我的事,叫我干啥就干啥,我是真正的劳动模范,不要怀疑 我会捣鬼。中断既来之,我就安之。不来之,则说明中断已经被禁掉了。肯定是有个幕后黑手已经调用CLI之类的指令关闭了全局的外部中断,然后偷偷摸摸干自 己相干的事情,不被其他人给打断。人都有自己的隐私嘛,代码也不例外。屏蔽中断,执行不被打断的代码,人之常情。但是用得不恰当,如同毒品一样,就会出现 大问题。少量鸦片,可以当作药品;携带超过5克海洛因,就得上刑场。禁掉中断占用一点点CPU时间,可以让程序很容易地绕开race condition(竞争条件);但是如果中断被禁掉的时间长达5秒钟,那就违反常理了。5秒钟之内系统不会有其他响应,其影响之深远,罪行之恶劣,不用 满清十大酷刑简直不足以平息民愤……”
 
“该杀!该杀!”这个时候,内存,芯片组,硬盘……所有硬件都附和。看来CPU还是一直是IT届的老大。不怪我们不客气了,赶紧打 印出现场(CPU出现LOCKUP时的相关上下文,包括寄存器值,函数调用栈等),且记入LOG,作为判案的证据,同时有警示后人只用。接着,就对施以极 刑,给内核来一个oops,彻底终止它的执行,让它重新启动。
 
3. 少林扫地僧——NMI
 
不对,不对!也许你有这样的感觉,既然5秒之内没有一个中断,基本肯定中断是已经被禁掉了,那CPU就被迫只会一直执行那段有问题 的代码,根本没有机会来执行所谓的“保留现场,强行重启”的代码。这些代码放在内核的另外一个地方,要调用它,必须由中断出发。可是,可是中断不是已经被 禁了吗?借尸还魂?恐怖,恐怖……
 
“再厉害的黑社会,也斗不过我们人民警察!”这个时候,CPU又冷笑了,“虽然中断被禁掉了,但是,我还拥有秘密武器。那就是 Non-maskable interrupt,不可屏蔽中断,简称NMI。你要禁,只能禁掉一般的可屏蔽中断。NMI,我压根就让你摸不着,碰不着!”
 
原来,内核中隐藏着一个神秘的高手,那就是NMI。我们调用spin_lock_irq,虽然能够禁掉本地的中断,但是NMI却不 行。内核中设置了一个watchdog timer,它的中断类型就被置为NMI,每过一定的时间,这个timer就执行一次,用来悄悄监视系统的运行。如果系统正常,它啥事都不做,仅仅是更改 一些时间计数;如果系统不正常(默认5秒没有任何普通外部中断),那它就闲不住了,会立马跳出来,且中止之前程序的运行。该出手时就出手!
 
我想到了在血腥的武林当中,有无数的高手。刚开始的时候,似乎人人都是高手;但后来,昔日的高手看起来都是菜鸟,强中更有强中手。 再后来,更高的高手出来了,开始这里论剑那里比武,争霸天下了。最后来,天下也许是第一第二的高手开始决战……似乎故事就这个时候结束了,但是让人大跌眼 镜的是,一个小小的少林扫地僧,却能轻易地两位顶尖高手制服。NMI就是这样的角色,平时从不站在前台,也很少为人所知。除了用NMI watchdog timer监测系统是否锁住之外,一些特殊的严重的硬件错误,比如内存奇偶校验错等,也会触发NMI的发生。不过这些错误,估计很多人从来不会碰到过。
 
4. More...
 
如果出现死循环的地方没有把中断禁掉,那是不是不会触发NMI watchdog timer了呢?理论上是的。至少Linux2.6的抢占内核应该不会触发。但是,由于系统还是有机会调度到其他线程,所以整个系统可能响应很慢,但不至 于给死掉。我们可以通过top命令查看进程状况等手段来进行分析。
 
不是所有的Linux内核都支持NMI watchdog timer的。必须在内核中添加APIC的支持。(现在的内核和硬件一般都是没有问题的)如果是x86-64的硬件体系结构,APIC是被默认支持的。在很多发行版本当中,需要在启动的时候添加内核启动参数
nmi_watchdog=N
来启动NMI watchdog timer。N代表了该timer的source,如果为1,表示利用IO APIC的始终源;如果为2,表示利用LOCAL APIC的performance counter。具体哪个好用,可以分别测试一下,一般来说,比较新的CPU(一般都是双核了)选择2的话,系统负担更小一点。想要更多的了解NMI watchdog timer,请看如下的kernel文档
http://www.kernel.org/doc/Documentation/nmi_watchdog.txt
想要知道啥时APIC(注意不是ACPI),啥是IO APIC,啥是LOCAL APIC,那就请google一下吧。

以上是关于watchdog机制的主要内容,如果未能解决你的问题,请参考以下文章

Android 进阶——SystemServer进程启动之Watchdog 详解

iOS-watchdog看门狗机制

Android 进阶——系统启动之SystemServer进程创建并启动Watchdog 监听系统服务详解

Android 进阶——系统启动之SystemServer进程创建并启动Watchdog 监听系统服务详解

分布式锁 Redission 介绍及使用其可重入锁 和 WatchDog 机制 和 MutiLock原理

Watchdog