如果说cfs是linux的一个很有创意的机制的话，那么linux中另一个创意就是nohz，我在前面已 经写了好几篇关于nohz的文章了，因此本文就不再阐述代码细节了，linux的创意在于设计而不在代码，代码主要解决的问题是实用性，就像gcc一样， 就是一个编译器，应用编译原理设计而出，它内部却充实着编译原理之外的巧妙。有血有肉才活得精彩，如果说nohz之前的linux内核是骨架的话，那么从 nohz之后，linux开始了精彩，之后几乎瞬时，cfs出现了，然后是cgroup...cgroup正式开始了虚拟容器，从此linux再也不用被 unix老大们看作是小孩子了，nohz标志着linux开始成熟起来。nohz为何这么重要呢？因为它直接关系到了性能，直接联系着系统的心跳，在之 前，系统总是被动的接受时钟中断，然后运行中断处理程序最终可能导致调度的发生，如果实在没有任务可以运行，那么就执行idle，这也许也算一种创意，可 是时钟中断还是会周期性的打破idle，然后查询有没有需要做的事情，如果没有继续idle，这种方式没有什么问题，可是我们总是希望系统可以主动的做些 事情，比如不是被动的接受中断而是主动的设置什么时候中断，因此必须将系统时钟发生中断这件事进行向上抽象，于是相应的clocksource和 clock_event_device，这两个结构体就是时钟以及时钟行为的抽象，clocksource代表了一个时钟源，一般都会有一个计数器，其中 的read回调函数就是负责读出其计数器的值，可是我们为何找不到write或者set之类的回调函数呢？这些回调函数其实不应该在 closksource中，而应该在clock_event_device中，实际上，clockevent只是一个钟，你可以类比我们用的钟 表，clocksource就是一个钟表，我们需要一个钟表就是需要读出它的指针的值从而知道现在几点，就是这些，因此钟表都会有显示盘用于读数，至于钟 表怎么运作，那就是钟表内部的机械原理了，记住，钟表就是用来读数的，另外我们为了害怕误事而需要闹铃，需要的是闹铃在一个时间段之后把我们唤醒，这是个 事情，而这个事情不一定非要有钟表，当然钟表的读数会为我们提供有用的参考值，这样的话钟表和闹铃就解耦合了，再重申一遍，不要因为有闹钟的存在就说钟表 都会响铃或者说闹铃都有钟表，它们其实是两个东西，钟表为你展示某些事情，而闹铃需要你的设置，设想一个场景，你手边有一个没有闹铃的钟表，还有一个没有 钟表的闹铃，这个闹铃只能设置绝对时间，然后到期振铃，你现在不知道几点，可是你要睡觉并且得到通知必须在四个小时后去参加一个聚会，那么你现在要做什 么？你肯定要看看你的钟表，然后设置你的闹钟。
以上的例子中，钟表就是clocksource，而闹钟就是clock_event_device，前者提供了一个指示盘，后者封装了闹铃到期以后的行为 以及设置闹铃的把手，就好像你的闹铃都有旋钮一样。既然操作系统的行为是时钟中断驱动的，那么它很符合我刚才例子中的那个逻辑，即使不用在内核中抽象出 clocksource和clock_event_device这些概念，只要能做到定时“振铃”，然后去执行时钟中断就可以了，2.6.18之前的内核 中在没有抽象出“钟表”和“闹铃”的情况下实现了上述的逻辑，可是这种方式有一个默认的前提就是内核一直有事可做，软件是硬件的奴隶，不得不在硬件的默认 前提下每隔一个时间段就被中断一次，而硬件只管定时中断而不管到底是否真正有事可做，理想的实现应该是将定时的任务交给内核自己，就好比我希望定一个闹铃 到一定时间后叫醒我，我希望我自己定这个闹铃而不是希望到时间我正在熟睡而被不知情的叫醒，2.6.18以前的内核中，根本就没有简单的“定闹铃”的把 手，因此不得不忍受硬件的有事无事的定时中断。clocksource和clock_event_device被抽象出来以 后，clock_event_device中有了定闹铃的把手，一切就醒目多了，实际上clocksource和clock_event_device被 抽象出来并不是为了nohz，而是为了将时钟相关的代码从平台相关的代码中分离出来，以便于独立修改统一管理，否则需要维护很多平台的不同的时钟处理代 码，而这些代码的逻辑大致相同，随后的2.6.22以后，nohz才出现，nohz其实就是托了抽象出来的clocksource和 clock_event_device的福，因为nohz直接需要设置下一次的中断时间而不是使用系统无条件的默认的HZ中断。 clock_event_device中的set_next_event就是定闹铃的把手，而event_handler则是可以让你自己定义闹铃到期后 的事件，就好比手机定闹铃时可以选到期后播放的音乐一样可以自定义事件处理回调函数。
本文转自 dog250 51CTO博客，原文链接:http://blog.51cto.com/dog250/1273491
