> For the complete documentation index, see [llms.txt](https://huataihuang.gitbook.io/cloud-atlas-draft/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://huataihuang.gitbook.io/cloud-atlas-draft/os/linux/kernel/cpu/irq_process.md).

# IRQ进程

我在使用NVIDIA的Jetson Nano设备时，注意到在使用图形界面时，经常看到有一个 `irq/xxx-nvidia` 进程占据较多CPU资源。这个是进程是内核的irq进程，和图形处理相关。

IRQ处理是操作系统的难点，因为中断在任何时候都可能触发，例如内核正在处理一个复杂都任务并且资源是反复无常的(例如指针可能指向了一个无效地址)。这个问题是通过 `锁` 来解决的，例如，在内核处于不可中断的持久化状态时，不允许中断处理器(interrupt handlers)运行。使用锁的缺点是，如果存在太多的锁会导致系统缓慢和低效。

这种情况下，更优的解决方案是：

* 内核中断处理时间越短越好
* 内核中断处理器的唯一工作就是将所有相关中断数据移动到一个临时缓存中
* 一些"后台"线程持续运行在这个临时缓存上，就像中断处理器一样完成中断处理

这些后台线程就是中断处理器内核线程：

* 从 `top` 命令上看这些中断处理内核线程是一个普通进程
* 但是，你会看到这些线程使用的内存是 **0**
* 这是真实的，因为这些内核中断处理线程不使用任何用户空间内存

你不能杀死内核线程，这些线程完全由内核管理。如果你杀掉内核线程，例如nvidia驱动的irq/142中断处理器，就会导致显卡发送中断没有任何线程能够处理。结果就是系统好像冻结了。

如果发现中断线程占用了太多的CPU资源，通常有以下一些原因：

* 硬件(如显卡)发送了太多的中断导致CPU无法处理
* 硬件有缺陷
* 驱动有缺陷

对于显卡驱动，出现bug的概率较高，通常通过reset驱动来解决，你也可以尝试：

* 停止一些3D加速进程
* 如果在运行X环境，切换到到字符界面然后切换回来，可以让显示驱动重新初始化
* 重启X

如果还不能解决，可以尝试移除Nvidia内核模块，重启X以便自动再次加载Nvidia内核模块。

## 参考

* [How do I kill an IRQ process in Linux?](https://unix.stackexchange.com/questions/387096/how-do-i-kill-an-irq-process-in-linux)