软中断（si）持续高于15%即表明网络收包或定时器任务在单核卡住，非业务代码问题；需用mpstat -p all 1查per-cpu %soft，结合watch cat /proc/softirqs观察net_rx/timer增速差异，并通过/proc/interrupts和msi_irqs确认硬中断分布及rps、rss、xps拓扑一致性。
软中断（si）持续高于 15%，基本就是网络收包或定时器类任务在单核上卡住了，不是业务代码问题，而是内核路径失衡。
怎么看是不是软中断真高了
别只信 top 第一行的平均值——多核机器上 si 是 per-CPU 的，95% 的软中断风暴都藏在某一个核里。用 mpstat -P ALL 1 每秒刷新一次，重点看哪一列的 %soft 突然飙到 60% 以上，其他核却还在个位数。同时执行 watch -d 'cat /proc/softirqs'，盯着 NET_RX 和 TIMER 这两列：如果某 CPU 的 NET_RX 增速是其他核的 10 倍以上，就是典型的收包不均；如果 TIMER 异常暴涨，可能有驱动或模块在狂注册微秒级定时器。
怎么确认硬中断全挤在 0 号核
软中断不均，八成是因为硬中断没散开。执行 cat /proc/interrupts | grep eth0（把 eth0 换成你实际网卡名），观察各 CPU 列数字。如果只有 CPU0 那列有百万级计数，其他全是 0 或几千，说明网卡中断全绑在 0 号核。再查硬件能力：ls /sys/class/net/eth0/device/msi_irqs/ 看有多少个 MSI-X 向量（即硬件队列数），它应该 ≥ CPU 总核数；如果只有 1 个，那再怎么调软件也白搭——得换支持多队列的网卡或更新固件。
RPS 和 netdev_budget 怎么配才不翻车
RPS（Receive Packet Steering）是软中断跨核分发的关键，但必须和 net.core.netdev_budget 配合着调：
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
-
/proc/sys/net/core/rps_cpu_mask不能为空，否则 RPS 实际是关闭的；设为ff（8 核）或ffff（16 核）表示允许所有核参与软中断处理 -
net.core.netdev_budget默认 300，盲目调大到 600 会让单次net_rx_action占用太久，反而阻塞调度器；千兆网卡建议 60–120，万兆建议 120–240 - 必须同步调大
net.core.netdev_max_backlog（建议 ≥5000），否则 budget 加大后丢包会转成延迟压力
改完记得验证：echo ff > /proc/sys/net/core/rps_cpu_mask，再跑 watch -d 'cat /proc/softirqs' 看 NET_RX 是否开始向多个 CPU 均匀增长。
为什么 ksoftirqd/0 一直在跑但业务没卡
看到 ksoftirqd/0 占 CPU 高，不代表业务一定受影响——关键要看它是否打断了你的业务线程。用 perf record -e 'irq:softirq_entry,syscalls:sys_enter_nanosleep' -C 0 -g -- sleep 10 抓一段 trace，再 perf script | grep -E '(net_rx|nanosleep)' 对比时间戳：如果 net_rx 软中断密集发生时，nanosleep 系统调用明显延迟，才说明它真在抢资源；如果两者时间错开，大概率只是空转，问题出在应用层或网卡驱动本身。
真正容易被忽略的是：软中断负载均衡不是单点调参能解决的，它依赖 RSS（网卡硬件队列）、RPS（内核软件分发）、XPS（发包队列绑定）三者映射一致。任意一个错位，比如 RSS 把包全打到 CPU0，RPS 却只允许 CPU1–3 处理，就会触发 soft lockup 日志，此时调 budget 没用，得先统一队列拓扑。
