禁用时钟中断,jiffies就不准了吗?

有关时钟中断，请多指教

陈老师：
您好，有幸拜读了您的《深入分析Linux内核源码》
一书。在读到时钟中断的时候有个疑惑老是缠绕着我。您在书中提到OS会每十一分钟去刷新RTC的时间，但OS的时钟计数是靠中断来进行的。但如果中断被长时间屏蔽的话，jiffies得不到该有的增加，再用它去刷新RTC的话，岂不是用错误的时间去同步正确的时间吗？希望您能看到我的留言。
[e-mail]
顶部
[广告] 推荐个超酷的web2.0相册
陈莉君
版主
Rank: 7Rank: 7Rank: 7


UID 26540
精华 1
积分 2281
帖子 152
LUPA币 2203 点
阅读权限 100
注册 2006-11-9
    
#2
发表于 2008-4-5 11:13  资料 个人空间 短消息
一般来说，RTC是OS 时钟的时间基准，操作系统通过读取RTC来初始化OS时钟，此后二者保持同步运行，共同维持着系统时间。保持同步运行是什么意思呢？就是指操作系统运行过程中，每隔一个固定时间（比如说每隔11分钟）会刷新或校正RTC中的信息。你担心的问题不会出现，因为每一个时钟中断jiffies的值都会增加1。

可以再仔细看看《ULK》第三版的第6章，定时测量。

[ 本帖最后由 陈莉君 于 2008-4-5 11:21 编辑 ]




透析真谛，似拨云穿雾；共享智慧，如春风沐浴

顶部
[广告] 推荐个超酷的web2.0相册
lin_2005
关注开源
Rank: 2



UID 174342
精华 1
积分 104
帖子 4
LUPA币 100 点
阅读权限 20
注册 2008-4-4
   
#3
发表于 2008-4-6 20:47  资料 短消息
仍有疑惑，请陈老师帮忙

我把定时测量这一章看了一下，仍然找不到问题的答案。
我的理解是
      只要时钟中断是可屏蔽的（通过8259A的任何一个引脚申请中断），那么中断的丢失是会有可能的（驱动程序又会经常关中断，这又增加丢失中断的概率）。若此时IRR寄存器的第0位为1（即IRQ0）CPU还没受理的情况下，8254又发送了一个中断请求，它也只是把IRR寄存器的第0位置1，对CPU来说应该无法知道之前置1的那个中断请求。虽然每一次时钟中断，中断服务程序都将jiffies加1，但如果要精确计时的话，应该要准确知道丢失的中断个数（如果有的话），这样才能准确计时，是不是这样子呢？如果是这样的话，软件时间是不可靠的，怎么会用它去写RTC呢？
     让我们想象这么一种极端的情况，若某个程序禁止外部中断，在那里死循环就是不开中断或是过一俩个钟头再开中断，这样即使8254不断地在IRQ0上发中断请求也不会得到受理,等到过了很久才开中断,再把jiffies加一,显然是不合适的.
     到底系统是靠哪种机制 正确计时的,请陈老师帮忙.再一次谢谢陈老师.
顶部
[广告] 推荐个超酷的web2.0相册
陈莉君
版主
Rank: 7Rank: 7Rank: 7


UID 26540
精华 1
积分 2281
帖子 152
LUPA币 2203 点
阅读权限 100
注册 2006-11-9
   
#4
发表于 2008-4-7 18:00  资料 个人空间 短消息
内核中除了使用可编程间隔定时器PIT外，还用到了时间戳计数器TSC（64位），高精度事件定时器HPET和ACPI电源管理定时器。后三种保证精确性。其中有一个mark_offset方法检查自上一个节拍以来是否丢失时钟中断，如果丢失，则更新Jiffies_64。