Linux内核中定义了jiffies变量来记录从系统启动到当前时刻系统时钟所产生的tick数。jiffies变量是一个无符号整型数值,即unsigned long类型。它的声明如下(在 include/linux/jiffies.h 中):
extern u64 __jiffy_data jiffies_64;
由此可见,jiffies变量在32位系统中的长度是32位,在64位系统中长度为64位。
在32位系统中,HZ=1000时,jiffies只要约 49.7 天就会发生回绕(溢出),而回绕会给内核时间度量带来混乱和其他潜在的问题。因此,在Linux2.6内核中引入一个64位的无符号整型变量jiffies_64,内核中计时都是对jiffies_64进行递增。jiffies_64也在 include/linux/jiffies.h 中有声明:
extern u64 __jiffy_data jiffies_64;
其中,u64为unsigned long long类型。在 1000HZ 的情况下,该变量运行几亿年都不会发出回绕,从而有效防止了回绕可能引起的问题。这就是定义jiffies_64变量的原因。
那么,既然在32位机器上也是用64位计时,为什么不直接把jiffies变量改为u64类型呢?或者说干脆用jiffies_64来代替jiffies呢?根本原因是为了保持兼容性及访问效率!从兼容性方面来看,大量的驱动程序使用jiffies 变量来进行一些与时间相关的操作,所以内核中需要保留该变量,以免影响系统功能;从访问效率方面来看,因为在 32 位的系统中访问 64 位的 jiffies_64 变量需要进行两次内存访问,一来访问速度没有直接访问 jiffies 来得快,二来无法保证原子性(在两次内存访问中间可能会被中断,从而造成读取数据的不正确)。但是当真的需要访问jiffies_64变量时(一般在驱动程序中很少访问 jiffies_64,通常只有内核核心代码才会访问),内核也提供了 get_jiffies_64() 函数来访问。该函数采用了加锁机制(xtime_lock),以防止读取数据的不正确。
虽然,jiffies和jiffies_64是两个变量,但它们最终指向相同的地址,只是jiffies取的是jiffies_64变量的低32位。这种效果通过链接程序实现的。通过链接器(ld)脚本 vmlinux.lds (x86 上位于 arch/x86/kernel下) 可看到:
1 OUTPUT_FORMAT("elf32-i386", "elf32-i386", "elf32-i386")
2 OUTPUT_ARCH(i386)
3 ENTRY(phys_startup_32)
4 jiffies = jiffies_64;
其中最后一条语句的作用是,让符号jiffies的地址等于符号jiffies_64的地址,即让jiffies变量占用 jiffies_64 的低 32 位。这里涉及到链接器中的一个重要的概念:
在目标文件内定义的符号可以在链接器脚本内赋值,此时该符号应被定义为全局的。每个符号都对应一个地址,在链接器中的赋值(=)操作就是更改这个符号对应的地址。
所以,这和 C 语言中的等于(=)是完全不同的概念:C 中是赋值,链接器中是改变地址。
另外,jiffies_64 变量会被初始化为 INITIAL_JIFFIES ,该值定义在文件 include/linux/jiffies.h 中:
1 /*
2 * Have the 32 bit jiffies value wrap 5 minutes after boot
3 * so jiffies wrap bugs show up earlier.
4 */
5 #define INITIAL_JIFFIES ((unsigned long)(unsigned int) (-300*HZ))
这样,就使得系统在启动后 5 分钟时发生 jiffies 回绕。这么做有利于及早暴露设备驱动程序中可能的 jiffies 回绕导致的逻辑错误,方便驱动程序的开发。
参考文献:
【1】:http://www.groad.net/bbs/thread-3352-1-1.html
【2】:http://bbs.csdn.net/topics/320154818
【3】:《Linux内核设计与实现(原书第3版)》第11章