直接查看/proc/interrupts得到的是自启动以来的中断累计计数，非实时频率；配合watch -n 1可观察单位时间增长速度，若某列每秒激增数千上万次，多属硬件异常或驱动未启用napi。
直接看 /proc/interrupts 就能知道中断频率
它不是“实时频率”，而是自启动以来的累计计数，但配合 watch 就能观察单位时间内的增长速度——这才是你真正关心的“频率”。数值每秒跳几十、几百次是常态；如果某行某列每秒涨几千甚至上万，基本说明设备在高频打中断，大概率是硬件异常或驱动没走 NAPI/轮询路径。
常见错误现象：cat /proc/interrupts 里 eth0 对应行的某一列数值狂涨，但 iftop 或 ss -i 显示网络流量并不高——这往往意味着网卡丢包重试、MSI 配置错误，或者驱动在低效地逐包触发中断。
- 用
watch -n 1 'grep eth0 /proc/interrupts'锁定网卡中断变化 - 对 NVMe 设备，改用
grep nvme /proc/interrupts，注意区分nvme0n1（块设备）和nvme0（控制器） - 别只盯总数：同一 IRQ 可能被多个 CPU 分摊，要横向比较各列（CPU0、CPU1…）是否严重不均
用 trace-cmd 抓单次中断耗时，定位卡顿根源
/proc/interrupts 只告诉你“发生了多少次”，但卡顿往往来自某次中断 handler 执行太久。这时候必须进 ftrace，而 trace-cmd 是最稳的入口。
先确认内核支持：grep CONFIG_IRQSOFF_TRACER /boot/config-$(uname -r) 输出得是 y 或 m。然后执行：
trace-cmd record -e irq:irq_handler_entry -e irq:irq_handler_exit -T 3
分析时重点看 delta 字段（单位纳秒），它等于 irq_handler_exit 时间减 irq_handler_entry 时间：
- 10–100 μs：可接受，但若频繁出现需检查是否在 handler 里做了内存拷贝或锁竞争
- > 100 μs：危险信号，尤其是音频、DPDK、实时控制等场景，可能直接导致丢帧或超时
别用 perf record -e irq:* 替代——它默认采样，不保证捕获每次 entry/exit 配对，且 delta 精度不可靠。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
查并调 smp_affinity_list，避免中断挤在单个 CPU 上
中断默认由内核分散，但某些设备（尤其老网卡或未启用 MSI-X 的 PCIe 设备）会把全部中断打到 CPU0，造成该核软硬中断密集，%si 和 %hi 拉满，其他核却空闲。
查当前绑定：grep eth0 /proc/interrupts | awk '{print $1}' | xargs -I{} sh -c 'echo IRQ{}: $(cat /proc/irq/{}/smp_affinity_list 2>/dev/null)'
修改前务必确认没被干扰：cat /proc/irq/*/effective_affinity，如果输出和 smp_affinity_list 不一致，说明 irqbalance 正在动态调整，或内核启用了自动亲和策略（如 irqaffinity= 内核参数）。
- 写入十进制编号更安全，例如绑到 CPU2 和 CPU3：
echo 2,3 | sudo tee /proc/irq/42/smp_affinity_list - 不要直接写十六进制掩码到
smp_affinity，x86_64 和 ARM64 的位宽不同，极易出错 - 改完立刻验证：
watch -n 1 'cat /proc/interrupts | grep eth0'，观察各 CPU 列是否开始均衡增长
硬件响应慢？先关掉 irqbalance 和节能策略再测
很多“中断响应慢”其实是软件层叠加上去的延迟：irqbalance 动态迁移中断引入 cache miss，CPU 频率缩放（ondemand governor）让核心在低频下处理中断，甚至 BIOS 中的 C-states 都会让唤醒延迟飙升。
临时排除干扰：
- 停掉 irqbalance：
sudo systemctl stop irqbalance - 切性能模式：
echo performance | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor - 禁用深睡状态（需 root）：
echo 1 | sudo tee /sys/module/kernel/parameters/noapic（慎用，仅调试）
这些操作本身不解决硬件问题，但能帮你确认：到底是设备真慢，还是系统调度/电源管理在拖后腿。真实硬件故障（比如 PCIe link width 降为 x1、NVMe 温度过高 throttle）往往会在关掉干扰后依然表现出高 delta 或高频率，这时才该查 lspci -vv、smartctl 或厂商诊断工具。
