linux 内核定时器的实现

发布时间：2020-12-13 23:13:15 所属栏目：Linux 来源：网络整理

导读：为了使用它们,尽管你不会需要知道内核定时器如何实现,这个实现是有趣的,并且值得看一下它们的内部. ? 定时器的实现被设计来符合下列要求和假设: ? 定时器管理必须尽可能简化. 设计应当随着激活的定时器数目上升而很好地适应. 大部分定时器在几秒或最多几分

为了使用它们,尽管你不会需要知道内核定时器如何实现,这个实现是有趣的,并且值得看一下它们的内部.

定时器的实现被设计来符合下列要求和假设:

定时器管理必须尽可能简化.
设计应当随着激活的定时器数目上升而很好地适应.
大部分定时器在几秒或最多几分钟内到时,而带有长延时的定时器是相当少见.
一个定时器应当在注册它的同一个 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 的定时器对于一个如同运行一个步进马达或者其他业余电子设备等简单任务是足够的,它常常是不合适在工业环境中的生产系统. 对于这样的任务,你将最可能需要依赖一个实时内核扩展.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!