为了使用它们, 尽管你不会需要知道内核定时器如何实现, 这个实现是有趣的, 并且值得 看一下它们的内部.
定时器的实现被设计来符合下列要求和假设:
- 定时器管理必须尽可能简化.
- 设计应当随着激活的定时器数目上升而很好地适应.
- 大部分定时器在几秒或最多几分钟内到时, 而带有长延时的定时器是相当少见.
- 一个定时器应当在注册它的同一个 CPU 上运行.
由内核开发者想出的解决方法是基于一个每-CPU 数据结构. 这个 timer_list 结构包括 一个指针指向这个的数据结构在它的 base 成员. 如果 base 是 NULL, 这个定时器没有 被调用运行; 否则, 这个指针告知哪个数据结构(并且, 因此, 哪个 CPU )运行它. 每- CPU 数据项在第 8 章的"每-CPU 变量"一节中描述.
无论何时内核代码注册一个定时器( 通过 add_timer 或者 mod_timer), 操作最终由 internal_add_timer 进行( 在 kernel/timer.c), 它依次添加新定时器到一个双向定时器 链表在一个关联到当前 CPU 的"层叠表" 中.
这个层叠表象这样工作: 如果定时器在下一个 0 到 255 jiffies 内到时, 它被添加到专 供短时定时器 256 列表中的一个上, 使用 expires 成员的最低有效位. 如果它在将来更 久时间到时( 但是在 16,384 jiffies 之前 ), 它被添加到基于 expires 成员的 9 - 14 位的 64 个列表中一个. 对于更长的定时器, 同样的技巧用在 15 - 20 位, 21 - 26 位, 和 27 - 31 位. 带有一个指向将来还长时间的 expires 成员的定时器( 一些只可能发生 在 64-位 平台上的事情 ) 被使用一个延时值 0xffffffff 进行哈希处理, 并且带有在过
去到时的定时器被调度来在下一个时钟嘀哒运行. (一个已经到时的定时器模拟有时在高 负载情况下被注册, 特别的是如果你运行一个可抢占内核).
当触发 run_timers, 它为当前定时器嘀哒执行所有挂起的定时器. 如果 jiffies 当前 是 256 的倍数, 这个函数还重新哈希处理一个下一级别的定时器列表到 256 短期列表, 可能地层叠一个或多个别的级别, 根据 jiffies 的位表示.
这个方法, 虽然第一眼看去相当复杂, 在几个和大量定时器的时候都工作得很好. 用来管 理每个激活定时器的时间独立于已经注册的定时器数目并且限制在几个对于它的 expires 成员的二进制表示的逻辑操作上. 关联到这个实现的唯一的开销是给 512 链表头的内存 ( 256 短期链表和 4 组 64 更长时间的列表) -- 即 4 KB 的容量.
函数 run_timers, 如同 /proc/jitimer 所示, 在原子上下文运行. 除了我们已经描述 过的限制, 这个带来一个有趣的特性: 定时器刚好在合适的时间到时, 甚至你没有运行一 个可抢占内核, 并且 CPU 在内核空间忙. 你可以见到发生了什么当你在后台读
/proc/jitbusy 时以及在前台 /proc/jitimer. 尽管系统看来牢固地被锁住被这个忙等待 系统调用, 内核定时器照样工作地不错.
但是, 记住, 一个内核定时器还远未完善, 因为它受累于 jitter 和 其他由硬件中断引 起怪物, 还有其他定时器和其他异步任务. 虽然一个关联到简单数字 I/O 的定时器对于 一个如同运行一个步进马达或者其他业余电子设备等简单任务是足够的, 它常常是不合适 在工业环境中的生产系统. 对于这样的任务, 你将最可能需要依赖一个实时内核扩展.