直接看 /proc/interrupts 可定位网卡 IRQ 号，但必须结合 /proc/irq/*/smp_affinity_list 才能准确确认绑定关系；grep 网卡名得 IRQ 号，多队列对应多行，末尾 IR-PCI-MSI 表示虚拟化环境，数值为 0 不代表无工作，smp_affinity_list 用十进制 CPU 编号更安全可靠。
直接看 /proc/interrupts 就能知道每个 IRQ 分配到了哪些 CPU，但必须配合 /proc/irq/*/smp_affinity_list 才算真正看清“谁绑在哪”。
怎么从 /proc/interrupts 快速定位目标设备的 IRQ 号
这一步是起点，不查准 IRQ 号，后面全白忙。
- 执行
grep eth0 /proc/interrupts（把eth0换成你的真实网卡名，比如ens33或enp3s0f0）——输出首列就是该设备占用的 IRQ 编号 - 如果看到多行（如
rx-0、rx-1），说明开了多队列，每行对应一个独立 IRQ，需逐个处理 - 注意末尾带
IR-PCI-MSI或IR-IO-APIC的行：这是虚拟化或启用了中断重映射的环境，IRQ 编号已和物理引脚解耦，不能按传统编号猜硬件 - 数值为 0 不代表没工作——
ethtool -C eth0 rx off后中断计数归零，但设备仍在轮询收包
为什么不能只信 /proc/irq/*/smp_affinity？用 smp_affinity_list 才安全
smp_affinity 是十六进制掩码，x86 和 ARM 位宽不同，写错直接导致中断不触发；而 smp_affinity_list 输出的是十进制 CPU 编号，人眼可读、跨架构通用。
- 查某 IRQ 绑定情况：例如 IRQ 42，运行
cat /proc/irq/42/smp_affinity_list，输出类似0,2表示只分发到 CPU0 和 CPU2 - 如果
/proc/irq/42/effective_affinity和smp_affinity_list不一致，说明irqbalance或内核自动管理正在覆盖你的设置 - 某些设备（如 BMC、老 RAID 卡）固件锁定 IRQ，
echo 0,2 > /proc/irq/42/smp_affinity_list会报Operation not permitted，先ls -l /proc/irq/42/确认有smp_affinity_list文件再动手
怎么确认中断真被绑定了？别只看文件，要验证实时分布
写完 smp_affinity_list 后，必须回看 /proc/interrupts 对应行各 CPU 列的数字增长是否符合预期，否则就是没生效。
- 启动监控：运行
watch -n 1 'grep eth0 /proc/interrupts'，观察几秒——如果只有 CPU0 列在涨，其他列为 0 或几乎不动，说明绑定失败或被覆盖 - 检查
irqbalance是否在捣鬼：systemctl is-active irqbalance，只要你在做低延迟或 DPDK 场景，必须sudo systemctl stop irqbalance并disable - NUMA 架构下，优先绑定到与网卡直连的 CPU 节点：用
lspci -vv -s $(ethtool -i eth0 | grep 'bus-info' | awk '{print $2}') | grep NUMA查节点，再用lscpu对照 CPU 编号
中断分配异常时，/proc/softirqs 往往比 /proc/interrupts 更关键
硬中断只是“敲门”，真正干活的是软中断；/proc/interrupts 看起来均衡，/proc/softirqs 却可能严重倾斜。
- 查软中断分布：
cat /proc/softirqs | grep NET_RX，对比各 CPU 列数值——如果 CPU0 是 CPU1 的 5 倍以上，说明下半部处理已成瓶颈 - 软中断默认在触发它的 CPU 上执行，所以硬中断绑得不均 → 软中断必然不均，
mpstat -P ALL 1中%soft持续 >20% 就该盯/proc/softirqs -
NET_RX高但硬件中断数很低？说明 NAPI 没生效，或者驱动在中断上下文里做了太多事（比如 memcpy 大块数据）
真正麻烦的不是找不到 IRQ 号，而是改了 smp_affinity_list 后发现数值没变、effective_affinity 和你写的不一致、或者 NUMA 节点对不上——这些细节漏掉一个，中断就还是打在错的核上。
