Linux内核系统时钟管理 感想总结 (未完待续)

目前讨论根据的是2.6.x 版本的内核

• 绝对时间: 所谓的绝对时间指的是系统流逝的时间,从你启动系统的那一时刻开始计算,直到你关闭系统的那一刻作为结束,这一段时间称之为系统流逝的时间（我叫做系统活了多长时间)
• 实际时间（墙上时间）: 就是现实生活中的时间,北京时间这种，就是实际时间
• 节拍器 (周期频率) : 发生了一次时钟中断, 就打了一个节拍
• 时钟中断间隔: 第一个节拍和第二个节拍的间隔
• 系统时钟频率: 就是1秒钟打了多少个节拍

总结： 内核中使用的是绝对时间,用户可以根据自己的选择怎么使用绝对的时间或者是实际的时间
我的习惯就是只要是底层驱动,选择绝对时间,对应dmesg(内核debug打印) 查找错误
应用层的化就选择实际时间,和别的系统交互的时候,方便系统授时

在做内核裁剪的时候，也有一个设置不知道大家注意过没,就是时钟频率设置有100HZ,1000HZ，当然还有更高的
这个有什么作用吗,第一个要知道,时间对系统的重要性, 没有时间的概念,就没有进程调度中的时间片的概念, 没有时间片,整个系统的进程调度,就没法做了,而所谓的linux 支持无时钟,其实是一种动态时钟调整的调整机制,为了降低整个系统的功耗(时钟中断如果一直触发,对系统来说也是一种很大的负担)
所以也就是说这个时钟设置,决定了系统调用的poll,select, 等系统轮询的API,精确度
1秒钟触发100次时钟中断,相当于触发一次的时间间隔10ms, 1000次就是1ms的时间间隔
这个时间其实就是执行一次最快轮询的时间
那么优点是什么大家一想就清楚，确定就是系统的功耗提高了,因为这个时钟中断无时无刻都在触发着,相对应的对系统的压力就很大
根据前人的实验总结: 这里面还有一个要点就是“事件”平均在设定时刻内发生,那么平均时刻内发生的概念值得的是就是半个节拍的时间: 0.5/*10ms = +/-5ms；1000Hz 这个精确度就是0.5ms的精确度
“事件指的是”，内核需要定时触发的任务,定时就意味着需要相关的精确度

内核的全局区有一个变量jiffies，随着时钟节拍逐渐增长, 关键是unsigned long 类型的数据最多也就是32位的长度,所以在系统运行个几十天以后，必然会发生溢出, 那么可以推断,所谓的jiffes其实和绝对时间相差无几,(而在内核中其实也是使用jiffies作为时间单位,秒的换算关系),但是这样的决策就意味着, 是不是溢出就没有任何事情了,其实不是,最开始的时候其实jiffes 指的就是两次时钟中断的时间间隔, 而关于jiffies的内核中的使用应该是不叫复杂应该是叫情况的多种讨论（现实情况就是在老的版本上一直,追加代码,优化,谁也不可能一次性做出完整的设计,现实的复杂程度很大）
内核中使用jiffies 用来计算和表示时间,记住这个狗东西很重要
所以 unsinged long 的分配的内存的大小是远远不够用的
为什么这样说咱们做一个简单的计算:
100HZ 的系统时钟频率: 在上面计算的时候, 100Hz 就是10ms 产生一次时钟中断 jiffes 增加1
unsigned long 是一个 32 位整型的数 又是无符号的那么最大值 4294967296 （1<<32）
(python3 是个好东西，matlab 更专业一点)
下面是计算流程
根据计算机结果发先,4971天 jiffes 这个就会溢出了
1000HZ 下的系统时钟频率: 那么在原有计算的结果上发现 4971/100 = 49.71 天 在1000Hz 的时钟频率下, 不到50天就溢出了,那么如果放任jiffes 的溢出，整个系统必然会瘫痪
所以在后来的版本更新中,在兼容来版本的基础上增加了 jiffes_u64 的变量 ，根据人的寿命来讲,不可能等到他发生溢出
为了兼容他是这样做的 jiffes = jiffes_u64 // 根据C 语言中 “=” 的拷贝赋值原则,小端模式下,jiffes 会被 jiffes_u64 的低32位 数填满
引入新的变量,兼容旧的变量这个问题就解决了吗, 现实告诉我们并没有,理论指导实践,但是需要实践来修正理论
资料上说是叫做jiffes 的回绕解决了这个问题

而在我看来 jiffes 就是一个简单的标志位，那我可不可以，使用事件触发 将 jiffes 清零,根据资料显示,说明的确是这么解决的
那么在内核系统中又一个重要的概念, 定时器出来了
在定时器中设置一个jiffes 可以达到的最大值,如果超过了这个最大值,就会清零,但是清零之后,新的问题又出现了