/proc/interrupts仅显示中断触发次数，无法反映延迟；真实中断响应延迟需用cyclictest（测调度延迟）、trace-cmd（定位高耗时中断）和irqtop（监控中断负载）等工具在RT内核下综合观测。
用 cat /proc/interrupts 看中断计数，但不能反映延迟
很多人第一反应是查 /proc/interrupts，它只显示每个 CPU 上各中断的触发次数，比如：
45: 1234567 0 0 0 PCI-MSI-edge eth0-rx-0
这个数字增长快慢能间接说明流量压力，但完全不包含时间信息——你无法从中知道某次中断从到来、被响应、到处理完成花了多少微秒。
真正衡量中断响应延迟，必须依赖内核实时性观测工具，且需在启用 RT 补丁或低延迟内核的前提下才有意义。
用 cyclictest 测中断延迟（含 IRQ 响应）
cyclictest 是 Linux 实时测试套件 rt-tests 中的核心工具，它通过高精度定时器触发周期性事件，并测量从定时器到期到线程实际被调度执行的时间差；当搭配中断负载（如网络收包）一起运行时，可观测到中断干扰导致的延迟尖峰。
- 安装：
sudo apt install rt-tests（Debian/Ubuntu）或sudo yum install rt-tests（RHEL/CentOS） - 基础命令：
cyclictest -t1 -p99 -i1000 -l10000（单线程、SCHED_FIFO 优先级 99、间隔 1000μs、运行 10000 次） - 加中断干扰测试：
taskset -c 0 cyclictest -t1 -p99 -i1000 -l10000 & stress --vm 1 --vm-bytes 1G & ping -f 192.168.1.1，观察Max Latency是否突增
注意：cyclictest 测的是“定时器到期 → 线程被调度”的延迟，不是纯硬件中断响应时间，但它能暴露中断处理不当引发的调度抖动——这才是真实场景中影响实时任务的关键瓶颈。
用 irqtop 和 trace-cmd 定位高延迟中断源
如果 cyclictest 显示延迟异常，下一步要确认是哪个中断在拖慢系统。默认没有 irqtop，需手动编译或使用 trace-cmd 抓取中断上下文行为：
-
sudo trace-cmd record -e irq:irq_handler_entry -e irq:irq_handler_exit -e sched:sched_switch（记录中断进出 + 调度切换） -
sudo trace-cmd report | grep -A5 -B5 "eth0\|nvme"快速定位网卡或 NVMe 相关中断耗时 - 重点关注
irq_handler_entry到irq_handler_exit的时间差，若超过 50μs，说明该中断处理函数存在优化空间
常见坑：某些驱动（尤其是老旧网卡或 USB 设备）在中断处理中做内存拷贝、锁竞争或调用可能阻塞的函数，导致中断上下文长时间占用 CPU——这类问题仅靠调整亲和性无法解决，必须换驱动或打补丁。
中断线程化（Threaded IRQ）开启后，/proc/interrupts 会多出 thread 字段
启用 RT 补丁或内核配置 CONFIG_IRQ_THREAD=y 后，部分设备驱动支持将中断下半部转为内核线程。此时 /proc/interrupts 的输出会变化：
45: 1234567 0 0 0 PCI-MSI-edge eth0-rx-0 45-thread
这意味着该中断的耗时逻辑已不在硬中断上下文中执行，而是由名为 irq/45-eth0 的内核线程承担，可被 SCHED_FIFO 调度、可设优先级、可被高优先级实时任务抢占。
验证是否生效：ps -eLf | grep "irq/[0-9]\+" | head -5；若看到类似 irq/45-eth0 进程且其 PR 值为 - 或数值很低，说明未启用线程化；若 PR 为 50~99，且 NI 可调，则已纳入 RT 调度器管理。
容易忽略的一点：不是所有中断都能线程化。只有注册时带 IRQF_ONESHOT 标志、且驱动显式支持的设备才启用——比如 Intel igb 驱动默认支持，而某些 Realtek RTL8169 驱动则不支持，强行设置会失败。
