Linux子系统系列-时钟子系统

年前处理了一个涉及linux时钟子系统比较麻烦的问题，问题虽然解决了，但在过程中遇到很多不太清晰地的地方，今天一起整理一下

由于本人涉猎不广，不思进取，所总结东西大部分来源于网络，希望能早日迈过这个层次，多有些自己的东西，一些自己在技术方面的积极思考。

+++++++++++++++++++++++++++++++++++++++++++++++++++++

目录：

1，时间在Linux的地位

2，Linux如何管理时间

3，时钟子系统的实现

4，在Linux中如何计时

5，Linux出了一个NO~HZ......

 

一，时间在Linux的地位

在一般操作系统中，很多活动都和时间有关，例如：进程调度，定时器任务，网络处理等等，内核中有大量的函数都是基于时间驱动的。记得在linux基础系列里面也提到了时钟相当于一个操作系统的“心跳”，操作系统没有了时钟也就想到于一个生物没有了心跳。所以说，了解Linux中的时钟处理机制有助于更好地了解Linux的运作方式。

 

二，Linux如何管理时间

一般说来，Linux内核主要需要两种类型的时间：
1. 在内核运行期间持续记录当前的时间与日期，以便内核对某些对象和事件作时间标记（timestamp，也称为“时间戳”，“墙上时间”，“实际时间”）。
2. 维持一个固定周期的定时器，以提醒内核或用户一段时间已经过去了。

无论我们说软件时钟还是硬件时钟，他们都是建立在时钟硬件基础上的。内核必须在硬件的帮助下才能计算和管理时间。硬件为内核提供了一个系统定时器用以计算流逝的时间，系统定时器以某种频率自行触发时钟中断，该频率可以通过编程设定。

在计算机系统中存在着许多硬件计时器(such as RTC, TSC, PIT. HPET etc...)，而且根据架构的不同而支持的不同的硬件计时器（such as TSC on Intel, TBH/TBL on PPC, and COUNT on MIPS）。

注：ARM架构目前没有专门的时间戳寄存器，所以也造成了在arm架构上没有标准的高精度接口export出来，能够使用的最大精度就是1/HZ秒。

 

通常来说，硬件时钟就是指直接使用硬件计时器作为驱动的时钟，软件时钟即指timer，他是在硬件时钟之上构建的一套定时器方法。

 

系统起来以后，系统被动的接受时钟中断，然后运行时钟中断处理程序，该ISR主要完成以下工作：

1，更新系统运行时间

2，更新墙上时间

3，如在SMP系统上，均衡调度程序中个处理器上的运行队列，使其负载均衡

4，检查当前进程是否用尽了自己的时间片。如果用尽，就重新调度

5，运行超时的动态定时器

6，更新资源消耗和处理器时间的统计值

注：以上内容很多来自于Love的LD3，就象生活不能没有爱，搞linux就不能缺少“Love”。

 

 

如果实在没有任务需要切换，执行完该ISR后，那么就执行idle，时钟中断会周期性的打破idle，然后查询有没有需要做的事情，如果没有继续idle，这基本上是linux中时钟管理的基本模式。 

 

三，时钟子系统的实现

 

我们知道，linux中各个子系统的实现都是一层层抽象的结果，时钟子系统也不例外。

 

1，原理

clocksource和clock_event_device两个结构被用来抽象linux的时钟管理：

 

• struct clocksource ：对硬件设备的抽象，描述时钟源信息
• struct clock_event_device ：时钟的事件信息，包括当硬件时钟中断发生时要执行那些操作，也可将该结构称作为“时钟事件设备”。

需要特别注意的是结构 clock_event_device 的成员 event_handler ，它指定了当硬件时钟中断发生时，内核应该执行那些操作，也就是真正的时钟中断处理函数。

 

Linux 内核维护了两个链表，分别存储了系统中所有时钟源的信息和时钟事件设备的信息。这两个链表的表头在内核中分别是 clocksource_list 和 clockevent_devices。

 

 

2，初始化

 

内核初始化部分（ start_kernel 函数）和时钟相关的过程主要有以下几个（内核版本2.6.34）：

 

tick_init();

init_timers();
hrtimers_init();

timekeeping_init();
time_init();

 

 

2.1 tick_init 函数

函数 tick_init() 很简单，调用 clockevents_register_notifier 函数向 clockevents_chain 通知链注册元素： tick_notifier。这个元素的回调函数指明了当时钟事件设备信息发生变化（例如新加入一个时钟事件设备等等）时，应该执行的操作，该回调函数为 tick_notify。并不是我们从字面意思理解的这个就是直接注册tick中断服务函数。

 

2.2 init_timers 函数

初始化本 CPU 上的软件时钟相关的数据结构，向 cpu_chain 通知链注册元素 timers_nb ，该元素的回调函数用于初始化指定 CPU 上的软件时钟相关的数据结构，最后初始化时钟的软中断处理函数。

 

2.3 hrtimers_init函数

高精度时钟定时器相关处理

 

2.4 timekeeping_init函数

涉及到另外内核子系统timekeeping subsystem，这里略过

 

2.5 time_init函数

初始化硬件时钟源和时钟事件信息，这个函数和硬件体系相关，各个架构都有不同的实现，这里就体现了linux分层抽象的魅力，一个子系统的设计会抽象成好几层，会尽力将和体系相关的部分放到一层，这样在不同架构上，该子系统就能做到尽量少的改动。

 

3，处理流程

主要关注time_init函数中的处理流程，该部分是和架构有关系的，不同架构的实现都各不相同，要具体分析。

以ARM架构为例，CPU为OMAP L138

3.1 在arch/arm/mach-davinci/time.c中，将架构相关的代码在此实现，并将davinci_timer_init挂载到davinci_timer中，我们在davinci_timer_init中将完成：

• timer硬件初始化
• setup clocksource 和clock event

3.2 在arch/arm/mach-davinci/board-da850-evm.c中设置MACHINE DES时，将davinci_timer挂到系统的timer上。

 

3.3 在arch/arm/kernel/setup.c中的setup_arch()函数，将会取出MACHINE DES中挂载的内容，对于timer，将会赋值到一个全局变量system_timer：

struct machine_desc *mdesc;

mdesc = setup_machine(machine_arch_type);

system_timer = mdesc->timer;

 

3.4 这样初始化完成后，arch/arm/kernel的time_init会最终调用system->init()完成time的设置。

 

四，linux中如何计时

1，用户侧

在用户空间中可以使用C语言函数gettimeofday 得到时间。

2，shell

 

在Linux的Shell下，我们经常也使用Shell内置的time命令和GNU版的time命令来测试程序运行的时间。

内置的time提供的参数选项比较少，而GNU的time则提供了丰富的参数选项，包括指定输出文件等功能。

[grandiose@Bygone grandiose]$ /usr/bin/time --output=foo.txt foo

上句只有时间信息输出到了foo.txt文件中，如果想要包括foo执行的结果，就需要按下句这样使用：

 [grandiose@Bygone grandiose]$ /usr/bin/time --output=foo.txt --append foo >foo.txt

如果想要控制输出时间的格式，可以使用-f开关进行格式化：

[grandiose@Bygone grandiose]$ /usr/bin/time    --output=foo.txt -f "//t%E real,//t%U user,//t%S sys" foo

如果仍需要使用Shell内置的time命令，可以用下面一句将结果输出至文件：

[grandiose@Bygone grandiose]$ (time foo) 2>foo.txt

这样写是因为内置命令time的输出是到标准错误的，文件描述符2表示标准错误stderr。如果还想要包括foo执行的结果，就要这样：

[grandiose@Bygone grandiose]$ (time foo) >foo.txt 2>&1

其中2>&1的含义是2与1 相同，一起送入foo.txt中。

nohup命令可以保证进程在退出系统之后仍能运行，这是它的常规用法。我们也可以这样使用nohup：

[grandiose@Bygone grandiose]$ nohup time foo

结果全部输出至nohup.out，也包括程序运行的时间信息。可以使用下面的语句将时间信息输出至文件foo.txt中。

 

[grandiose@Bygone grandiose]$ tail -2 nohup.out > foo.txt

3，内核侧

如果要定制自己的设备驱动程序，可能就会用到内核里的计时功能。Linux内核空间中的计时与用户空间

的计时不太相同。在内核空间里，有一个全局变量Jiffies维护着当前的时间。与系统时钟有关的调用有

#include <asm/param.h> #include <linux/timer.h> void add_timer(struct timer_list * timer); int del_timer(struct timer_list * timer); inline void init_timer(struct timer_list * timer); 

五，linux来了一个NO~HZ

NOHZ对于linux意味着什么呢，dog250兄表述的很到位（以下完全来自dog250兄的博文：

http://blog.csdn.net/dog250/archive/2010/02/09/5303566.aspx）：

 如果说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中。实际上，clocksource只是一个钟，你可以类比我们用的钟表，clocksource就是一个钟表，我们需要一个钟表就是需要读出它的指针的值从而知道现在几点，就是这些，因此钟表都会有显示盘用于读数，至于钟表怎么运作，那就是钟表内部的机械原理了，记住，钟表就是用来读数的。另外我们为了害怕误事而需要闹铃，需要闹铃在一个时间段之后把我们唤醒，这就是个event，而这个event不一定非要有钟表，当然钟表的读数会为我们提供有用的参考值，这样的话钟表和闹铃就解耦合了，再重申一遍:

不要因为有闹钟的存在就说钟表都会响铃或者说闹铃都有钟表，它们其实是两个东西，钟表为你展示某些事情，而闹铃需要你的设置，设想一个场景，你手边有一个没有闹铃的钟表，还有一个没有 钟表的闹铃，这个闹铃只能设置绝对时间，然后到期振铃，你现在不知道几点，可是你要睡觉并且得到通知必须在四个小时后去参加一个聚会，那么你现在要做什么？你肯定要看看你的钟表，然后设置你的闹钟。

以上的例子中，钟表就是clocksource，而闹钟就是clock_event_device，前者提供了一个指示盘，后者封装了闹铃到期以后的行为以及设置闹铃的handler，就好像你的闹铃都有旋钮一样。既然操作系统的行为是时钟中断驱动的，那么它很符合我刚才例子中的那个逻辑，即使不用在内核中抽象出 clocksource和clock_event_device这些概念，只要能做到定时“振铃”，然后去执行时钟中断就可以了，2.6.18之前的内核中在没有抽象出“钟表”和“闹铃”的情况下实现了上述的逻辑，就是我们上面所说的硬件时钟中断模式。可是这种方式有一个默认的前提就是内核一直有事可做，软件是硬件的奴隶，不得不在硬件的默认前提下每隔一个时间段就被中断一次，而硬件只管定时中断而不管到底是否真正有事可做，理想的实现应该是将定时的任务交给内核自己，就好比我希望定一个闹铃到一定时间后叫醒我，我希望我自己定这个闹铃而不是希望到时间我正在熟睡而被不知情的叫醒。

 2.6.18以前的内核中，根本就没有简单的“定闹铃”的handler，因此不得不忍受硬件的有事无事的定时中断。clocksource和clock_event_device被抽象出来以 后，clock_event_device中有了定闹铃的handler，一切就醒目多了，实际上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中一次性的设置，而且被封装了，可以随时设置，新的设置方式 显得更加直观。