Linux中的中断处理方法

1:中断处理是需要注意的几点

(1)在中断上下文中,不能和用户空间数据交互,也就是不能使用copy_to_user()和copy_from_user()。

(2)中断上下文中,不能交出CPU(不能休眠、不能schedule、不能被打断)。

(3)ISR运行时间尽可能短,越长则系统响应特性越差,为了节省中断运行的时间,所以内核采用上半部分和下半部分的方式来处理中断。

2:中断上下半部的两种解决方案

(1)为什么要分上半部(top half,又叫顶半部,上半部分负责登记和记录中断,并激活下半部,让下半部得以执行)和下半部(bottom half,又叫底半部,下半部分主要负责真正的处理)。

(2)下半部处理策略1:tasklet(小任务)。

引入tasklet,最主要的是考虑支持SMP,提高SMP多个cpu的利用率;不同的tasklet可以在不同的cpu上运行。但是tasklet属于中断上下文,因此不能被阻塞,不能睡眠,不可被打断。

(3)下半部处理策略2:workqueue(工作队列)。

workqueue的突出特点是下半部会交给worker thead,因此下半部处于进程上下文,可以被重新调度,可以阻塞,也可以睡眠。workqueue的初始化方式有静态和动态两种。

静态初始化:

调用宏DECLARE_WORK,初始化一个中断的上半部,然后在中断上半部调用schedule_work()启动我们的中断下半部

动态初始化

调用宏 INIT_WORK,初始化一个中断的上半部,然后在中断上半部调用queue_work()启动我们的中断下半部

简单地说,一般的驱动程序的编写者需要做两个选择。 首先,你是不是需要一个可调度的实体来执行需要推后完成的工作――从根本上来说,有休眠的需要吗?要是有,工作队列就是你的惟一选择。 否则最好用tasklet。要是必须专注于性能的提高,那么就考虑softirq。

3:中断上下半部处理原则

(1)必须立即进行紧急处理的极少量任务放入在中断的顶半部中,此时屏蔽了与自己同类型的中断,由于任务量少,所以可以迅速不受打扰地处理完紧急任务。也就是要把执行时间短,紧急的任务放在上半部。

(2)需要较少时间的中等数量的急迫任务放在tasklet中。此时不会屏蔽任何中断(包括与自己的顶半部同类型的中断),所以不影响顶半部对紧急事务的处理;同时又不会进行用户进程调度,从而保证了自己急迫任务得以迅速完成。也就是说,我们在上半部调用task_schedule去唤醒我们的下半部时,下半部并不是马上被执行,系统会根据此时的CPU的使用情况,来选择下半部是马上被执行还是延时一段时间执行,假设在延时期间产生了一个上半部的中断,那么上半部就可以被先执行。

(3)需要较多时间且并不急迫(允许被操作系统剥夺运行权,也就是可以被调用)的大量任务放在workqueue中。此时操作系统会尽量快速处理完这个任务,但如果任务量太大,期间操作系统也会有机会调度别的用户进程运行,从而保证不会因为这个任务需要运行时间将其它用户进程无法进行。

(4)可能引起睡眠的任务放在workqueue中。因为在workqueue中睡眠是安全的。在需要获得大量的内存时、在需要获取信号量时,在需要执行阻塞式的I/O操作时,用workqueue很合适。

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/13596.html