linux新内核的时钟机制代码

http://blog.chinaunix.net/uid-22810130-id-384173.html

如果说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中一次性的设置，而且被封装了，可以随时设置，新的设置方式显得更加直观.

hrtimer 及clockevent/source的引入对于kernel的实时性的提高有很大贡献，也将clock的处理从体系结构的代码中抽象了出来，增强了代码的可重用性。并且对于posix的time／timer标准有了强有力的支持，提高了用户空间的应用程序的时间处理精度及灵活性。如果应用层在使用这些syscall时有任何不解之处，直接看看hrtimer的code，对于处理问题，理解OS的行为都有很大帮助。

linux内核的nohz与hres

设计linux内核的那帮家伙想的可真周到啊，前面说过，linux内核的性格就是激情，只要硬件设计的足够灵活，那么设计者就会尽可能的发挥，不放过任何可自由发挥的点和死角，而且他们从来不管后果，有时还毅然抛弃硬件的建议，最新内核的nohz可谓是一项创举。时钟中断是计算机系统必须的，就像人必须有心跳一样，人的心跳是周期的，计算机系统的“心跳”也是周期的，因此，时钟中断每隔固定的时间就会发生。真的是这样吗？linux内核的设计者认为如果cpu在空闲态，那么就没有必要心跳了，毕竟计算机不是一个自组织系统，能源全靠外界电源供给，而人是一个自组织实体，因此人必须要有周期的心跳来自己产生能量，计算机的外界电源只要不断，加上时钟可编程，那么非周期心跳甚至心跳停止就是可能的，linux内核实现了这一点。在2.6.21内核之前，时钟中断是周期的，在那之后引入了新的时钟封装结构clock_event_device和 clocksource（参见我前面的两篇文章），于是可以更加灵活的实现自己设计的个性时钟，这个个性时钟就是nohz方式和hres方式。当然系统初启的时候时钟中断还是周期的，当timer_interrupt被调用的时候，就会触发timer软中断，然后在接下来的软中断处理中找机会切到nohz 或者hres，具体代码如下：

void run_local_timers(void)

{

hrtimer_run_queues();   //优先处理高精度时钟队列

raise_softirq(TIMER_SOFTIRQ);  //触发软中断，处理函数见下：

softlockup_tick();

}

static void run_timer_softirq(struct softirq_action *h)//软中断处理函数

{

hrtimer_run_pending();           //这里有机会切换到nohz或者hres

}

void hrtimer_run_pending(void)

{

struct hrtimer_cpu_base *cpu_base = &__get_cpu_var(hrtimer_bases);

if (hrtimer_hres_active())    //如果已经是了，就没有必要切换了，直接返回

return;

if (tick_check_oneshot_change(!hrtimer_is_hres_enabled()))  //这个if判断就是具体切换到hres或者nohz的代码

hrtimer_switch_to_hres();

run_hrtimer_pending(cpu_base);

}

int tick_check_oneshot_change(int allow_nohz)

{

struct tick_sched *ts = &__get_cpu_var(tick_cpu_sched);

if (!test_and_clear_bit(0, &ts->check_clocks))  //由此开始的种种判断说明切换所需要到种种条件

return 0;

if (ts->nohz_mode != NOHZ_MODE_INACTIVE)

return 0;

if (!timekeeping_valid_for_hres() || !tick_is_oneshot_available())

return 0;

if (!allow_nohz)     //如果hres是允许的，那么返回1，这样就会切换到hres高精度模式了

return 1;

tick_nohz_switch_to_nohz();  //如果没有机会切换到高精度模式，前面种种验证均通过，这里最起码切换到了nohz模式

return 0;

}

hres模式和nohz模式的具体切换由hrtimer_switch_to_hres和tick_nohz_switch_to_nohz负责。不能光一味的跟踪代码，hres和nohz有何关联呢又分别是什么意义呢？hres实际上也不是周期中断的，而是很精确的确定中断，用最近到时的hrtimer的触发时间来对时钟编程从而在那个时间到来的时候触发中断，而nohz仅仅说明可以用非周期的时间对时钟编程，对精度没有要求。在hres中，一切事物都由一个 hrtimer负责，比如原来的节拍调度，统计当前进程的时间等操作直接在timer_interrupt进行，而hres模式下，上述操作专门有一个 hrtimer，当clock_event_device的event_handler执行时（所有操作都被封装进了 clock_event_device的event_handler，而此event_handler在切换到hres或者nohz的时候被赋值），该函数遍历所有的hrtimer，所有的hrtimer组织成红黑树，将到期的hrtimer链入一个链表，然后在软中断中执行这个链表的hrtimer的回调函数，对于别的hrtimer则马上执行：所有hrtimer分为两类，一类不能在软中断中执行，属于比较紧急的，另一个可以在软中断中执行，属于不那么紧急的。对于纯粹的nohz非hres模式，event_handler中还是传统的处理方式，只不过下次中断的时间可以任意编程。这种方式中，时间测量可以达到钠秒的精度。 
每当cpu执行cpu_idle的时候，内核就会找机会停掉系统的心跳，然后在适当时机触发心跳，而不是周期的心跳，这个时机是什么呢？如果一切都由 hrtimer负责了，那么这个时机就是找出的最近到期的timer的到期时刻，虽然停掉了周期的时钟中断，但是别的硬件中断是没有停掉的，而硬件中断可能触发一些事件，比如调度，比如发布一个新的timer，因此，每次硬件中断后都要检查最新的hrtimer的到期情况和重新调度请求，如果有那么马上停掉关心跳模式切出idle进程。下面的代码体现了这一点，在每次进入硬件中断处理的时候都要调用irq_enter：
 void irq_enter(void)

{         __irq_enter();

#ifdef CONFIG_NO_HZ

if (idle_cpu(cpu))

tick_nohz_update_jiffies();  //更新计时，nohz模式由此来作为触发下一中断的时机参考。怎么理解呢？看看这个调用条件，只有在cpu处于idle状态时才更新时间，因为cpu处于idle时可能已经将周期时钟停掉了，为了不遗失时间信息，必须在中断中补上。

#endif

}

nohz 模式下的中断“几乎”是周期的，nohz的字面意义就是非周期，但是它还是基本周期的，因为它没有任何下一个时钟中断的时间点依据；但是hres却是完全随机时钟中断的，因为它的event_handler中就是操作红黑树上的hrtimer们，因此，它完全可以将下一个到期的hrtimer的到期时刻作为下一个触发时钟中断的时刻，要知道在hres模式里面，所有的时间相关的操作比如计时，节拍调度等都是由hrtimer负责的，如果要选择下一次触发时钟中断的时机就不能在某一个hrtimer的处理函数里面仲裁了，而必须在全局的处理所有的hrtimer的event_handler函数里面仲裁，这就是一切。我们看一下cpu_idle：

void cpu_idle(void) {}

其中tick_nohz_stop_sched_tick里面调用了next_jiffies = get_next_timer_interrupt(last_jiffies);这一句，此句的意思就是找出下一个最近的timer或者hrtimer 用来将其到期时间作为下一个时钟中断的时间。在tick_nohz_stop_sched_tick中当然要检查重新调度标志，如果置位那么马上返回不再 nohz了，其实在每个硬件中断后的irq_exit里都要调用tick_nohz_stop_sched_tick函数用来在可能的情况下重新对时钟编程。 
看来linux的设计者考虑的就是周到，这又是一个疯狂的使用并且灵活的发挥硬件作用的例子，linux本身不区分中断优先级在某种意义上纵容了nohz 和hres的出现和发展，如果有一天linux内核变得规则了，有原则了，像windows一样了或者说向unix靠齐了，那么linux的时代也就过去了，它的性格也就磨平了。