linux设备驱动七（时间、延迟及延缓操作）

知识点：如何度量时间差，如何比较时间如何获得当前时间如何将操作延迟指定一段时间如何调度异步函数到指定时间之后执行度量时间差HZ指一秒内产生的时钟中断次数，即时钟中断频率jiffies_64记录自上一次操作系统引导以来的时钟滴答数。即使在32位架构上也是64位。驱动程序通常访问jiffies变量。它是unsigned long类型，要么和jiffies_64相同，要么仅仅是jiffies_64的低3

oscube

2774人浏览 · 2020-08-03 08:02:05

oscube · 2020-08-03 08:02:05 发布

知识点：

如何度量时间差，如何比较时间
如何获得当前时间
如何将操作延迟指定一段时间
如何调度异步函数到指定时间之后执行

度量时间差

HZ指一秒内产生的时钟中断次数，即时钟中断频率

jiffies_64记录自上一次操作系统引导以来的时钟滴答数。即使在32位架构上也是64位。

驱动程序通常访问jiffies变量。它是unsigned long类型，要么和jiffies_64相同，要么仅仅是jiffies_64的低32位.使用它的原因是访问快，而对64位的访问不是在所有架构删都是原子的。

使用jiffies

jiffies有溢出的问题，比较时应该使用宏：

time_afer timer_before time_after_eq time_before_eq

有时需要将来自用户空间的时间表述方法（struct timeval和struct timespec）与内核表述方式进行转换。使用：

timespec_to_jiffies jiffies_to_timespec timeval_to_jiffies jiffies_to_timeval

32位架构中，jiffies_64的访问不是原子的，不能直接读取，应该使用辅助函数get_jiffies_64

通过/proc/interrupts的计数值除以/proc/uptime报告的系统运行时间，即可获得确切的HZ值

处理器特定的寄存器

大部分的CPU设计中，指令时序本质上不可预测，依赖于指令周期的经验型性能描述方法不再使用，CPU制造商引入了一种通过计算时钟周期来度量时间差的方法。

使用一个随时钟周期不断递增的计数寄存器，最有名的计数器寄存器就是TSC（时间戳计数器）

rdtsc（low32,high32）;

rdtscl(low32);

rdtscll(var 64); 64位在可能会溢出的情况下使用。但这些函数是x86专用的。

get_sycles是一个体系结构无关的函数，在不支持计数器寄存器的平台上返回0

时间戳计数器不会再SMP的多个处理器保持同步，为获得一致的值，需要使查询该计数器的代码禁止抢占。

获取当前时间

内核一般使用jiffies来获取当前时间，该值表示最近一次系统启动到当前的时间间隔

驱动程序可以利用jiffies来测量不同事件的时间间隔

如果要测量更短则职能使用处理器特定的寄存器

墙钟时间（日常生活中的时间），有更高的策略相关性，不能归于内核，内核也提供了将墙钟时间转为jiffies的函数：mktime

do_gettimeofday在许多体系结构上有接近微妙级的分辨率，依赖实际的硬件机制。

也可以通过直接访问xtime变量获得当前时间，但是精度要差一些，因为很难原子的访问，所以不建议直接访问。提供了函数curent_kernel_time

延迟执行

涉及多个时钟滴答的延迟称为“长延迟”

常常与时钟滴答的延迟可以使用系统时钟，非常短的延迟通常必须用软件循环。

长延迟：

长于一个时钟滴答

忙等待

while(time_before(jiffies, jl)) cpu_relax();

跟具体架构相关，不执行大量的处理器代码，某些系统可能不做任何事情，也可能把CPU让给其他现成，但是仍然应该避免。

忙等待严重降低系统性能，内核配置为非抢占时，循环会锁住处理器。配置为抢占时，可以用作他用，但仍然有些浪费。

如果进入循环之前，禁止了中断，jiffies则不会更新，此时wilie条件永远为真

让出处理器

while(time_before(jiffies,jl)) schedule();

当系统中只有一个进程，调度器还是回调度它，而空闲任务（Idle进程号是0）得不到调度。运行Idle会降低CPU负荷。

还有一个问题是可能导致等待时间更长，在延迟时间到达时，CPU在执行其他任务。

超时

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

long wait_event_interruptible_timeout(queue_head_t_q, condition, long timeout);

超时到期返回0，如果由其他事件唤醒，返回剩余时间，不会返回负数，即使超过了等待时间。参数timeout是要等待的jiffies值，不是绝对时间。如果传递的是负数会产生oops

signed long schedule_time(signed long timeout);

可以避免使用多余的等待队列，但是首先要设置当前进程的状态。set_current_state

调度器会在超时时间到期且其状态变成TASK_RUNNING时才会运行这个进程

如果没有设置状态，则和调用schedule的作用是一样的，内核构造的定时器不会真正起作用

短延迟

void ndelay(unsigned long nsecs);

void udelay(unsigned long usecs);

void mdelay(unsigned long msecs);

udelay和ndelay传递的参数设置了上线，如果模块无法加载，并显示为解析的符号__bad_udelay，则说明调用udelay传递了太大的值

一般规则，上前毫秒应使用udelay，而不是ndelay，毫秒级延迟应使用mdelay，而不是其他粒度。

这三个函数都是忙等待函数。

非忙等待的毫秒级延迟函数

void msleep(unsigned int millisecs);

unsigned long msleep_interruptible(unsigned int msec); 返回0，被提前中断返回剩余毫秒数。

void ssleep(unsigned int seconds);

内核定时器

内核定时器可用来在未来某个特定时间点（基于时钟滴答）调度执行某个函数。

这个函数是异步执行的，而启动这个定时器的进程可能正在休眠火灾其他处理器上执行，也可能已经推出了。

内核定时器常常作为软件中断的结果来运行的。不处于进程上下文中。

不处于进程上下文时，应该遵循的规则：

- 不允许访问用户空间，没有进程上下文，无法将任何特定进程与用户空间关联
- current指针在原子模式下没有任何意义，也是不可用的，因为相关代码和被中断的进程没有任何关联
- 不能执行休眠或调度，例如schedule或wait_event，以及GFP_KERNEL为标记的kmalloc，信号量等等。

in_interrupt()函数，处于中断上下文时返回非零值

in_atomic()函数，调度不被允许时，返回非零值，包括了中断上下文，以及拥有自旋锁的时候。此时current可用使用，但禁止访问用户空间，因为这回导致调度的发生

另外一个特定是，可以在定时器函数中再次注册自己稍后执行，这是因为函数执行前会从链表中移除

在SMP系统中，为了获得缓存的局部性（locality），定时器只会在注册他的同一CPU执行

异步执行导致并发，可能产生竟态，注意保护。

定时器API

void init_timer(struct timer_list *timer)

struct timer_list TIMER_INITIALIZER(_function, _expires, _data);

void add_timer(struct timer_list *timer)

void del_timer(struct timer_list＊timer)

expires = jiffies + tdelay

int mod_timer(struct timer_list *timer, unsigned long expires)

int del_timer_sync(struct timer_list* timer) 可以在SMP系统上避免竟态发生，非原子上下文中调用，可能会休眠，其他情况进入忙等待，调用该函数之前，持有了锁，定时器函数企图获取相同锁可能导致死锁，定时器函数中如果重新注册自己，在调用该函数应该设置标记，确保不发生重新注册

int timer_pending(const struct timer_list *timer) 定时器是否在被调度运行

内核定时器实现

定时器用到了per-cpu变量，timer_list中的base域指向该变量

add_timer时，内核会将timer_list加入到512个链表头构成的级联链表中的一个链表上。具体加入哪个链表按照下面的方式计算：

如果在0-255个jiffies中到期，加入前256个链表中的一个，取决于expires字段低8位

256-16384个jiffies中到期，256 - 256 + 63，这64个链表中的一个取决于expires字段的9-14位

更远的定时器，依次放在下面的3组64个链表中，分别取决于15-20位，21-26位，27-31位，超过超过了32位，则利用延迟值0xffffffff做散列运算

__run_timers被激发时，会执行当前时钟滴答上的所有挂起的定时器，如果jiffies当前是256的倍数，还会将下一级定时器链表重新散列到256个短期链表中，同时可能根据上jiffies的位划分对其他级别的定时器做级联处理。

__run_timers运行在原子上下文中，即使不是抢占式内核，系统忙等待，定时器仍然能够很好的工作（分析原因？）

定时器会受到硬件中断和其他定时器及异步任务的影响，适合步进电机和业余电子设备，不适合工业环境下的生产系统

tasklet

和定时器相同的是：

始终在中断期间执行，

始终在调度他们的同一CPU上运行

tasklet也会在软件中断上下文以原子模式执行（原子模式怎么理解？）

和定时器不同的是：

tasklet不能要求在某个给定时间执行。

相关函数：

void tasklet_init(struct tasklet_struct *t, void (*func)(unsigned long), unsigned long data);
DECLARE_TASKLET(name, func, data);
DECLARE_TASKLET_DISABLED(name, func, data);
void tasklet_disable(struct tasklet_struct *t); 该函数仍然可以用tasklet_schedule调度，但其执行被推迟，知道该tasklet被重启。如果tasklet当前正在运行，该函数会进入忙等待知道tasklet函数退出。因此，在调用该函数之后，可以确信该tasklet不会再系统中的任何地方运行
void tasklet_disable_nosync(struct tasklet_struct *t);该函数返回后，tasklet直到重启之前不会再被调度，但是有可能已经开始执行，该函数不会等待tasklet执行完毕。
void tasklet_enable(struct tasklet_struct *t);重启一个被禁止的tasklet，必须和tasklet_disable匹配调用，因为内核对每个tasklet保存有一个禁用计数。
void tasklet_schedule(struct tasklet_struct *t);未开始执行，多次调用该函数也只会执行一次，已经开始执行，会在执行完毕后，再次运行。通过这种方式，可以重启自己。
void tasklet_hi_schedule(struct tasklet_struct *t);以高优先级执行，会在处理其他软件中断任务之前处理高优先级的tasklet，低延迟需要的任务调用。
void tasklet_kill(struct tasklet_struct *t);确保指定的tasklet不会再次调度运行，已经开始执行，该函数等待其推出，和del_timer_sync相同，应该避免在调用tasklet_kill之前完成重新调度。

特性：

tasklet可以在稍后被禁用或启用，只有启动和禁用次数相同，tasklet才会被执行

tasklet也可以注册自己本身

tasklet可被调度在通常的优先级或者高优先级执行，高优先级的tasklet总会首先执行

如果系统负荷不重，则tasklet立即得到执行，但始终不会晚于下一个定时器滴答（最晚下一个滴答会运行，这个怎么来保证？）

一个tasklet可以和其他tasklet并发，但对自身来讲是严格串行处理的。同一个tasklet永远不会在多个处理器上同时运行。

void tasklet_enable(struct tasklet_struct *t);启用一个被禁用的tasklet，必须和tasklet_disable成对调用，因为tasklet保存有一个禁用计数

void tasklet_schedule(struct tasklet_struct *t);调度一个tasklet，还没有开始执行，多次调用也只会执行一次，如果已经开始执行了，在完成后会再次运行。

工作队列

和tasklet区别：

tasklet运行在中断上下文，工作队列运行在内核进程上下文，工作队列可以休眠，tasklet不能。
tasklet始终运行在被初始提交的同一个处理器上，而工作队列是可以配置的。
内核代码可以请求工作队列函数在指定延迟后执行
tasklet会在很短的时间段内快速执行，而工作队列没有这个限制

相关函数：

- struct workqueue_struct *create_workqueue(const char *name); 内核会在系统中每个处理器上为该工作队列创建专用线程。
- struct workqueue_struct *create_singlethread_workqueue(const char* name); 如果单个线程足够使用，使用该函数
- DECLARE_WORK(name, void (*func)(void *), void *data);静态声明一个work_struct
- INIT_WORK(struct work_struct *work, void (*func)(void *); void *data); 首次构造之后，使用该函数初始化
- PREPARE_WORK(struct work_struct *work, void (*func)(void *), void *data); 如果该结构已经被提交到工作队列，使用该函数修改
- int queue_work(struct workqueue_struct *queue, struct work_struct *work);
- int queue_delayed_work(struct workqueue_struct *queue, struct work_struct *work, unsignend long delay);加入工作队列，但是work_struct实际工作至少在指定时间之后执行。如果已经在队列中，则这两个函数都返回1.返回非0，表示工作已经在队列中，不能多次加入。
- int cancel_delayed_work(struct work_struct *work); 返回非0，表示工作不会再执行。返回0，则表示工作可能已经在执行了。因此该函数返回之后，工作仍然可能在运行，
- void flush_workqueue(struct workqueue_struct *queue);上面一个函数返回0时，应该调用该函数，该函数调用之后，在该函数调用之前提交的工作函数不会再执行
- void destroy_workqueue(struct workqueue_struct *queue);