Linux中断管理

CPU和外设之间的交互，或CPU通过轮询机制查询，或外设通过中断机制主动上报。

对大部分外设中断比轮询效率高，但比如网卡驱动采取轮询比中断效率高。

这里重点关注ARM+Linux组合下中断管理，从底层硬件GIC+CPU，到Linux内核通用部分处理，再到GIC驱动以及中断注册，最后是中断下半部软终端、tasklet、workqueue，包括线程化部分。

所以按照从硬件到软件，软件从底层到上层的框架去介绍。

0. 目录

《Linux中断管理》

《Linux中断管理 (1)Linux中断管理机制》

《Linux中断管理 (2)软中断和tasklet》

《Linux中断管理 (3)workqueue工作队列》

1. 思考问答

• 发生硬件中断后，ARM处理器做了哪些事情？

SoC内部中断控制器会感知到中断信号，中断控制器里的仲裁单元(Distributor)会在众多CUP核心中选择一个，并把该中断分发给CPU核心。

GIC控制器和CPU核心之间通过一个nIRQ信号来通知CPU。

CPU核心感知到中断发生之后，硬件会自动做如下一些事情：

• 保存中断发生时CPSR寄存器的内容到SPSR_irq寄存器中
• 修改CPSR寄存器，让CPU进入处理器模式中的IRQ模式，即CPSR寄存器中的M域设置为IRQ Mode
• 硬件自动关闭中断IRQ或FIQ，即CPSR中的IRQ位或FIQ位置1
• 保存返回地址到LR_irq寄存器中
• 硬件自动跳转到中断向量表的IRQ向量中

• 硬件中断号和Linux内核的IRQ中断号是如何映射的？

硬件中断号的映射是在系统启动过程中接卸DTS，然后经由irq_domain_alloc_irqs()完成映射到Linux中断号。

中断发生后，根据硬件中断号经由irq_find_mapping()找到Linux软中断号。

• 一个硬件中断发生后，Linux内核如何响应并处理该中断？

一个硬件发生后，LInux软件的起点是中断向量表vector_irq。

vector_irq根据中断发生时状态决定是进入用户空间__irq_svc还是内核空间__irq_svc。

两者主要工作都交给irq_handler处理，irq_handler调用中断控制器处理函数gic_handle_irq()。

gic_handle_irq()根据读取到的硬件中断号转换成Linux中断号，然后进行特定中断处理。

从中断返回时，还需要实现如下两个操作：

• 从SPSR_irq寄存器中恢复数据到CPSR中
• 从LR_irq中回复内容到PC中，从而返回到中断点的下一个指令处执行。

• 为什么说中断上下文不能执行睡眠操作？

所谓的睡眠，就是调用schedule()让出CPU，调度器选择另外一个进程继续执行，这个过程涉及进程栈空间的切换。

如果中断上下文中调用schedule()，此时获取的struct thread_info数据结构是发生中断是该进程栈信息，而不是中断上下文调用schedule()时任何信息。

这就导致再也无法返回中断上下文中调用schedule()的地方。

另一个原因是，中断上下文处于关中断中，需要发送一个EOI通知GIC中断处理结束，GIC和CPU Interface才会进入下一次中断处理。如果中途schedule()，那么整个系统的中断都会被屏蔽掉。

• 软中断的回调函数执行过程中是否允许响应本地中断？

软中断回调函数执行处于开中断环境下，所以允许响应本地中断。

具体参考__do_softirq()，在执行h->action()前打开本地中断，完成后关闭中断。

• 同一类型的软中断是否允许多个CPU并行执行？

同一类型的软中断可以在多个CUP并发执行，因为软中断处理函数是可重入的，自身对数据进行了保护。

• 软中断上下文包括哪几种情况？

中断上下文包括硬中断上下文和软中断上下文，当然也包括NMI上下文。

软中断上下文包括三部分：

一是在下半部执行的软中断处理包括tasklet，调用过程是irq_exit()->invoke_softirq()；

二是ksoftirqd内核线程执行的软中断，比如强制中断线程化force_threads，或者软中断执行时间太长仅为唤醒ksoftirqd内核线程；

三是进程上下文中调用local_bh_enable()时也会去执行软中断处理，调用过程是local_bh_enable()->do_softirq()。

一属于传统意义的中断上下文，二、三运行在进程上下文中，但三者统称为软中断上下文。

• 软中断上下文和进程上下文哪个优先级高？为什么？

软中断上下文优先级高于进程上下文，因此软中断包括tasklet总是抢占进程的运行。参见irq_exit()退出中断时优先执行softirq。

比如当进程A在运行时发生中断，在中断返回时如果不处于中断上下文且有pending的softirq时，优先执行软中断包括tasklet。

然后采取检查是否有高优先级任务需要签章中断点的进程。

这样导致的危害是：如果执行软中断或者tasklet事件过长，那么高优先级任务就长时间得不到运行，严重影响系统的实时性。

这也是RT补丁强制将softirq处理函数线程化的原因。

• 是否允许同一个tasklet在多个CPU上并行执行？

不允许同一个tasklet同时在多个CPU并发执行，taskelt必须固定在一个CPU上串行执行。

因为tasket被挂入到per-cpu的taskelt_vec中，并且设置TASKLET_STATE_SCHED标志位，那么只能由该CPU来执行。

直到执行完毕并清除了TASKLET_STATE_SCHED后，其它CPU才有机会执行。

• workqueue试运行在中断上下文，还是进程上下文？其回调函数允许睡眠吗？

• 旧版本(Linux 2.6.25)的workqueue机制在实际过程中遇到了哪些问题和挑战？

• CMWQ机制如何动态管理工作线程池的线程呢？

• 如果有多个work挂入一个工作线程中执行，当某个work的回调函数执行了阻塞操作，那么剩下的work该怎么办？