听说有人抱怨他的Linux服务器或者嵌入式Linux开发板上的时间越来越慢，当时念头一闪，没有多在意
今天顿悟，果然是有道理的

用户空间的延时和定时器，都是靠内核定时器实现的。内核定时器 struct timer_list 以及相关内核api，
init_timer()、add_timer、mod_timer 、del_timer，都依赖于jiffes
一个系统时钟中断，jiffes就加1，每秒将产生 1*HZ 个jiffes
可以说，这个jiffes，也可称为滴答，等于是OS的心跳，靠着这个稳定长期的中断，内核才能够及时从一个时间片到期的进程手中夺回cpu的使用权，进行下一次调度。当然，每一次中断结束或者返回用户空间都可能进入调度，所以这里用词是及时。
2.6.21版本开始支持无滴答内核，据说能够节能。不过我想没有了滴答，内核定时器失效，很多软件怕是要重写了，所以大家都不大关注这个。

常见的计算机系统会带有一个RTC，这个才是可靠的墙上时钟源。
不过访问rtc的速度比较慢，所以只是上电的时候，内核读取一次rtc时间，之后在OS里看到的时间都是靠一个一个jiffes加上去的。

很多时候，为了保护临界资源，不得不关闭所有中断，这个在中断处理函数中尤为常见。那么就有可能在关闭中断后的临界区，发生了系统时钟中断，这次时 钟中断就被忽略了。导致jiffies没有增加，进而影响系统时钟精度。这个概率我只能定性的分析。比如arm上HZ为100，pc上为1000，那么每 隔10ms或者1ms就能有一次时钟中断。而10ms期间，200MHZ的arm芯片大约能执行 0.5M 条指令，正好落在临界区的几百条指令的概率不是很大。但是计算机跑起来微小的误差也是很容易积累的，所以如有必要，可以另开一个守护进程，定时读取rtc 来修正系统时间。

手工验证一下
spinlock_t lock;
unsigned long flags;

static int test_timer_init_module(void)
{
spin_lock_init(&lock);
printk( KERN_DEBUG "Module test_timer init\n" );
spin_lock_irqsave(&lock, flags);
printk( KERN_DEBUG "the jiffies is %ld\n" ,jiffies);
mdelay(2000);
printk( KERN_DEBUG "the jiffies is %ld\n" ,jiffies);
spin_unlock_irqrestore(&lock, flags);
return 0;
}

不加黑色代码，两个jiffes相差 20xx??? ，pc上HZ为1000，这个结果还是正常的
加上黑色代码，关闭中断2000ms，两个jiffes没有差别

所以写驱动一定要自律，关闭中断后的代码一定要尽可能的简洁迅速