pidstat -u 5无法查看进程引发的中断，它仅统计%usr/%system CPU时间，不采集IRQ或softirq数据；真正追踪需用/proc/interrupts、/proc/softirqs或trace-cmd等内核级工具。
Linux里没有“进程产生的中断”这种东西——中断是硬件或内核子系统触发的，pidstat、top、ps这类进程级工具根本看不到中断向量、IRQ编号或软中断队列。想归因到某个进程，得换思路：不是“谁发了中断”，而是“谁让中断变多/变慢”。
为什么 pidstat -u 5 看不到中断来源
pidstat -u 5 能看到的，其实只是进程跑在用户态和内核态上的 CPU 时间，也就是 %usr 和 %system。至于中断计数，它不采；IRQ 关联，它不做；softirq 的执行上下文，它同样不会记录。所以，哪怕你看到 %system 很高，背后的原因也未必只有一种：可能是系统调用卡住了，可能是锁竞争上来了，可能是页错误变多了，也可能是进程一次次被软中断调度器抢占。问题就在这里——仅靠它，根本分不清 NET_RX 到底是 nginx 在收包触发的，还是 dpdk 应用在持续轮询。
pidstat输出里永远不会出现INTR、IRQ、softirq字段- 加
-w看上下文切换、加-d看 I/O，也只是间接线索，不是中断本身 - 误以为
pidstat -u 5能替代cat /proc/interrupts，等于拿温度计去测电压——工具不在同一层
怎么判断某个进程是否加剧了中断负载
真正要查“某进程是否导致中断飙升”，得从设备行为反推：它是否让网卡持续收包？是否频繁触发磁盘 I/O？是否绑定了 ksoftirqd？
- 查该进程是否在处理网络流量：
ss -tulpn | grep $(pgrep -f your_process)，如果监听端口且cat /proc/softirqs | grep NET_RX某 CPU 列同步猛涨，就是强相关 - 查是否引发大量磁盘中断：用
iotop -p $(pgrep -f your_process)看 I/O rate，再对比grep nvme /proc/interrupts或grep ata /proc/interrupts是否同步跳变 - 看它是否绑定了软中断线程：
ps -eLf | grep ksoftirqd | grep -E "(CPU[0-9]|$(pgrep -f your_process))"，若发现ksoftirqd/0的comm和你的进程共用 tid，说明它正在消耗该核的 softirq 处理能力
trace-cmd 是唯一能关联进程与中断 handler 的方式
只有 trace-cmd 能抓到中断 handler 入口，并通过调用栈回溯到触发它的上下文——但这不是“进程发中断”，而是“中断 handler 执行时，哪个进程刚被调度出去/正在睡眠”。
- 先确认内核支持：
grep CONFIG_IRQSOFF_TRACER /boot/config-$(uname -r)必须返回y或m - 只追踪特定进程关联的中断入口：
trace-cmd record -e irq:irq_handler_entry -g -p $(pgrep -f your_process) -T 3 - 分析时重点看
comm字段（当前进程名）和backtrace，如果栈里有net_rx_action→igb_poll→schedule，说明网卡收包后调度了你的进程 - 注意：
perf record -e irq:*不可靠——入口/出口事件不配对，delta字段算不准，别用
容易被忽略的关键点
别把中断理解成进程里的“子任务”——它本质上是异步事件。无论是硬中断号（IRQ），还是软中断类型（比如 NET_RX），都不存在和进程 PID 一一对应的映射关系。所谓“某个进程把中断打高了”，说到底，往往是它触发了设备侧的行为，比如持续调用 recv()，让网卡一直收发数据；又或者它把 CPU 吃得太满，结果导致 ksoftirqd 调度被拖慢，软中断只能越积越多。真想把问题查清楚，光盯着 ps 远远不够，必须把视角切到 /proc/interrupts、/proc/softirqs 和 trace-cmd 这三层，少看一层都不行。
