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。
参考
http://blog.csdn.net/cupidove/article/details/49927259
http://blog.csdn.net/xujianqun/article/details/6778529
3：中断上下半部处理原则
（1）必须立即进行紧急处理的极少量任务放入在中断的顶半部中，此时屏蔽了与自己同类型的中断，由于任务量少，所以可以迅速不受打扰地处理完紧急任务。也就是要把执行时间短，紧急的任务放在上半部。
（2）需要较少时间的中等数量的急迫任务放在tasklet中。此时不会屏蔽任何中断（包括与自己的顶半部同类型的中断），所以不影响顶半部对紧急事务的处理；同时又不会进行用户进程调度，从而保证了自己急迫任务得以迅速完成。也就是说，我们在上半部调用task_schedule去唤醒我们的下半部时，下半部并不是马上被执行，系统会根据此时的CPU的使用情况，来选择下半部是马上被执行还是延时一段时间执行，假设在延时期间产生了一个上半部的中断，那么上半部就可以被先执行。
（3）需要较多时间且并不急迫（允许被操作系统剥夺运行权，也就是可以被调用）的大量任务放在workqueue中。此时操作系统会尽量快速处理完这个任务，但如果任务量太大，期间操作系统也会有机会调度别的用户进程运行，从而保证不会因为这个任务需要运行时间将其它用户进程无法进行。
（4）可能引起睡眠的任务放在workqueue中。因为在workqueue中睡眠是安全的。在需要获得大量的内存时、在需要获取信号量时，在需要执行阻塞式的I/O操作时，用workqueue很合适。
本文转自 菜鸟养成记 51CTO博客，原文链接:http://blog.51cto.com/11674570/1951161
