如果说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则是可以让你自己定义闹铃到期后 的事件，就好比手机定闹铃时可以选到期后播放的音乐一样可以自定义事件处理回调函数。
cfs调度和HZ分离了，clocksource和clock_event_device封装了时钟以及其操作，以往的进程在特定的固定时间片内运行，时 钟的定时中断提供了时间片的监督工作，一切显得十分和谐，可是系统内核本身就是没有主权，一切都在硬件的安排下进行，clocksource和 clock_event_device被抽象出来以后，内核有了一定的主权，它可以在运行时设置硬件了，内核的运行和硬件的特性进一步解除耦合，内核不再 是奴隶了，它终于可以作为主人设置硬件本身了，cfs调度器之后，关于进程以及整个系统的运行特性彻底从底层硬件的时钟中分离了，完全采用linux的逻 辑进行，再也不用受制于底层的时钟以及时间片分配特性，linux可以按照自己的方式来进行调度，或者用自己的方式设置下一个中断的到来时间，这难道还是 中断吗？中断的含义就是异步到来的事件，clock_event_device的set_next_event致使系统明确的知道下一个中断什么时候到 来，这其实没有什么不对，就是因为它是时钟相关的，而时钟中断在老的版本的内核里面的中断间隔也是确定的。新的内核越来越多的将硬件把手抽象给内核，或者 将内核把手抽象给用户，这样的内核显得越来越成熟了，内核可以通过硬件把手操控硬件从而影响运行时的策略，而用户可以通过内核把手操控内核从而影响内核的 运行时策略。内核对下面的硬件可以控制了，对上面的用户空间也提供了很多不错的操作接口，三层的联系越来越紧密但是却没有增加耦合性，实在是妙！
clocksource是一个钟表，clock_event_device是一个闹铃，它们可以合并为一个闹钟，也可以单独行动，既然 clock_event_device是一个闹钟而且必然拥有定闹铃的把手（set_next_event），那么时钟中断就是由这个 clock_event_device来设置的了，设置的中断到来以后，还是这个clock_event_device负责用event_handler 来唱一支歌，毕竟它是闹铃，闹铃要负责在到期后响铃的，而且除了响铃也可以做别的，而clocksource只是一个可以从中得到一个读数的一个源头罢 了，如果说谁要是有疑问，觉得如果一个clocksource没有中断功能却成功的成了一个全局的主要clocksource，那么怎么办？没有问题，设 置中断和clocksource有没有中断功能没有关系，只要clock_event_device的set_next_event中有设置中断硬件的逻 辑就可以了。比如tsc时钟源没有中断功能，它是一个高精度计数器，那么在系统的clock_event_device中的set_next_event 中必须实现设置当前中断源的代码。用clocksource和clock_event_device实现的新的时钟逻辑更像是一个软件定时器。
既然硬件时钟可以由运行中的内核软件驱动了，那么很多机制都随之变得灵活起来，比如hrtimer的实现，比如时钟中断的实现等等，在nohz模式中，在 cpu进入idle之前要进入ick_nohz_stop_sched_tick，这个函数中可能就会停掉时钟中断，如果停掉的话，那么在每次其他硬件中 断执行完之后会再次进入这个函数以检测timer队列是否被更新，或者定时器到期后，系统会重新开启间隔为tick_period的时钟中断，这个可以用 hrtimer实现，也可以用别的机制实现。为了维持系统内cpu的负载均衡，所有开启nohz停掉cpu的idle进程不能全部都停掉cpu进入 halt，而是要有一个进行idle load balance，为何不能让别的cpu代劳呢？因为别的cpu忙着呢？只要处于idle状态的cpu比较闲，因此就由它来负责所有的停掉的cpu的负载均 衡工作，一旦有进程被拉到了这些cpu上，那么马上唤醒它们，这在load_balance函数代码中有描述：
if (ld_moved && this_cpu != smp_processor_id())
resched_cpu(this_cpu);
以上的片段就是说一旦有进程拉到了this_cpu上并且这个cpu不是当前的执行load_balance的cpu，那么就发送ipi唤醒处于nohz停止状态的cpu，因为由于系统不平衡，它已经不能再继续睡下去了。
前面一篇文章说了，由于2.6.23之前的内核的进程调度只要是基于时间片的，而时间片的计算又没有办法找到一种比较统一的方式，这个原因就是内核对硬件 的控制力弱加上操作系统内核的抽象机制严重依赖底层的硬件配置，你可以将HZ设置到1000甚至更高(HZ不能随意高，必须依照cpu硬件来设置，HZ能 设置多高不在于你的代码多高效，而是在于你的cpu有多快)，可是你却要面对新的问题，比如时间片跨度太大的响应慢问题，时间片跨度太小导致的高优先级进 程不怎么优先问题或者低优先级时间片和HZ相关并且有时过小导致的cache频繁失效问题，虽然双斜率机制解决了部分问题，可是又引入了新的问题，比如 nice 0两端不对称问题。在新的cfs中，调度行为不再依赖HZ的值，并且在时钟相关的操作抽象成clocksource和 clock_event_device之后，底层的时钟硬件不再被在start_kernel中一次性的设置，而且被封装了，可以随时设置，新的设置方式 显得更加直观。
阅读(1490) | 评论(0) | 转发(0) |
