linux 基于 jiffy 的超时

到目前为止所展示的次优化的延时循环通过查看 jiffy 计数器而不告诉任何人来工作. 但是最好的实现一个延时的方法,如你可能猜想的,常常是请求内核为你做. 有 2 种方 法来建立一个基于 jiffy 的超时,依赖于是否你的驱动在等待其他的事件.

?

如果你的驱动使用一个等待队列来等待某些其他事件,但是你也想确保它在一个确定时间 段内运行,可以使用 wait_event_timeout 或者 wait_event_interruptible_timeout:

?

#include <linux/wait.h>

long wait_event_timeout(wait_queue_head_t q,condition,long timeout); long wait_event_interruptible_timeout(wait_queue_head_t q,long timeout);

?

这些函数在给定队列上睡眠,但是它们在超时(以 jiffies 表示)到后返回. 因此,它们 实现一个限定的睡眠不会一直睡下去. 注意超时值表示要等待的 jiffies 数,不是一个 绝对时间值. 这个值由一个有符号的数表示,因为它有时是一个相减运算的结果,尽管这 些函数如果提供的超时值是负值通过一个 printk 语句抱怨. 如果超时到,这些函数返回 0; 如果这个进程被其他事件唤醒,它返回以 jiffies 表示的剩余超时值. 返回值从不会 是负值,甚至如果延时由于系统负载而比期望的值大.

?

/proc/jitqueue 文件展示了一个基于 wait_event_interruptible_timeout 的延时,结 果这个模块没有事件来等待,并且使用 0 作为一个条件:

?

wait_queue_head_t wait; init_waitqueue_head (&wait);

wait_event_interruptible_timeout(wait,delay);

?

当读取 /proc/jitqueue 时,观察到的行为近乎优化的,即便在负载下:

?

?

因为读进程当等待超时( 上面是 dd )不在运行队列中,你看不到表现方面的差别,无论 代码是否运行在一个抢占内核中.

?

wait_event_timeout 和 wait_event_interruptible_timeout 被设计为有硬件驱动存在,这里可以用任何一种方法来恢复执行: 或者有人调用 wake_up 在等待队列上,或者超时 到. 这不适用于 jitqueue,因为没人在等待队列上调用 wake_up ( 毕竟,没有其他代码 知道它 ),因此这个进程当超时到时一直唤醒. 为适应这个特别的情况,这里你想延后执 行不等待特定事件,内核提供了 schedule_timeout 函数,因此你可以避免声明和使用一 个多余的等待队列头:

?

?

163