直接查看/proc/interrupts可获中断分布，但需结合设备类型、cpu亲和性、软中断及irqbalance状态综合判断是否失衡；关键在识别单cpu上异常飙升的特定irq（如eth0、nvme），并验证其软中断（/proc/softirqs）与业务线程是否同步均衡。
直接看 /proc/interrupts 就能知道系统中断分布，但光看数字没用——得结合设备、CPU亲和性、软中断和 irqbalance 状态一起判断是否真存在失衡。
怎么快速定位高干扰中断源
中断失衡往往不是“所有中断都多”，而是某几个 IRQ 在单个 CPU 上疯狂增长，把那个核拖垮。关键不是总量，是分布斜率。
-
cat /proc/interrupts输出里找最后一列含eth0、nvme、msi或IO-APIC的行，再盯紧某一个 CPU 列（比如 CPU1）数值是否远高于其他列 - 用
watch -n 1 'cat /proc/interrupts | grep "eth0\|nvme"'实时观察——如果某行某列每秒涨几百甚至上千，基本就是它在捣鬼 - 注意
RES（重调度）、CAL（IPI）、TIMER这类内核中断持续飙升，通常说明进程调度异常或有 busy-loop，不是硬件问题 -
ethtool -S eth0 | grep -E "(rx_packets|rx_interrupts)"：若rx_interrupts远大于rx_packets（比如 5:1），说明 NAPI 没生效，网卡在“包包中断”，得查 GRO/LRO 和 RSS 队列数
为什么改了 smp_affinity 还没用
手动写 /proc/irq/42/smp_affinity 后过几秒又变回去？八成是 irqbalance 在后台偷偷覆盖你。
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
-
systemctl status irqbalance必须先确认服务状态；只要你在做低延迟或绑核优化，sudo systemctl stop irqbalance && sudo systemctl disable irqbalance是强制动作 -
smp_affinity是十六进制掩码，0x01= CPU0，0x03= CPU0+CPU1，但现代系统更推荐用smp_affinity_list（如echo 0,2 > /proc/irq/42/smp_affinity_list），可读性高且避免位运算错误 - 写入前确认该 IRQ 是否支持动态调整：
ls -l /proc/irq/42/中要有smp_affinity*文件；某些固件锁定的中断（如某些 BMC 或老 RAID 卡）写入会报Operation not permitted - NUMA 架构下，优先把网卡 IRQ 绑到与该网卡直连的 CPU 节点（用
lscpu和lspci -vv -s $(ethtool -i eth0 | grep bus-info | awk '{print $2}') | grep NUMA交叉验证）
软中断（softirq）堆积比硬件中断更隐蔽
/proc/interrupts 只统计硬件 IRQ 触发次数，而 NET_RX、NET_TX、RCU 这些软中断在 /proc/softirqs 里，它们不占 IRQ 编号，但吃 CPU 更狠，且容易被误认为是“进程占用”。
-
cat /proc/softirqs查看各 CPU 上 softirq 执行次数，重点关注NET_RX列——如果 CPU1 的值是其他核的 5 倍以上，且mpstat -P ALL 1显示该核%soft持续 >20%，说明下半部处理已成瓶颈 - 软中断不绑定 CPU，但执行受当前运行核限制；它会在中断退出后立即在**触发它的那个 CPU** 上执行，所以 IRQ 绑定不均 → softirq 也必然不均
- 不能只调 IRQ，还得配合网卡多队列：用
ethtool -l eth0看最大通道数，再用ethtool -L eth0 combined 4开足队列，最后确保每个队列有独立 IRQ（cat /proc/interrupts | grep eth0应看到多个不同 IRQ 号） - RSS（接收侧缩放）必须与网卡驱动、固件、交换机 flow control 全链路匹配；否则即使开了 8 个队列，流量仍全打到第一个 IRQ
真正难的不是改哪一行配置，而是确认改动后有没有形成闭环：IRQ 分散了 → 对应的 softirq 是否同步摊开 → 业务线程是否真的没再被同核中断打断 → L1/L2 缓存命中率有没有回升。这些必须用 perf stat -C 1 -e cycles,instructions,cache-references,cache-misses 对比验证，而不是只盯着 /proc/interrupts 数字变小就收工。
