perf top中[ksoftirqd]占比高通常源于网络软中断处理瓶颈，需通过/proc/net/softnet_stat分析dropped和time_squeeze字段判断是否因netdev_budget过小、RSS不均或NAPI未启用导致。
perf top 看到 [ksoftirqd] 占比高，先确认是不是软中断瓶颈
这通常不是 CPU 被“占满”了，而是网络软中断（NET_RX）在 ksoftirqd 线程里持续被唤醒、处理不过来。关键要区分：是收包太快（网卡 flood），还是单核处理能力不足（如 RSS 未开启或不均），或是 net.core.netdev_budget 设置过小导致每次只处理少量包就让出 CPU，引发高频调度开销。
检查 softnet_stat 判断是否丢包和 backlog 积压
/proc/net/softnet_stat 每行对应一个 CPU 的软中断统计，用十六进制解析前两个字段：
- 第 1 字段（
processed）：该 CPU 上成功入队并处理的包数 - 第 2 字段（
dropped）：因input_pkt_queue满或内存不足被丢弃的包数 —— 若持续增长，说明软中断处理速度跟不上入队速度 - 第 3 字段（
time_squeeze）：表示一次软中断上下文中，因超时（默认 2 jiffies）提前退出，被迫下次再处理 —— 高值直接指向netdev_budget过小或单次处理耗时过高
例如：echo "0x$(awk 'NR==1 {print $1}' /proc/net/softnet_stat | cut -d' ' -f1)" | bc 查当前 CPU 的 processed；重复执行对比增速，若 time_squeeze 增速 > processed，基本可断定预算不足。
netdev_budget 不是越大越好，需结合 NAPI 和中断合并调
net.core.netdev_budget 控制每次软中断上下文最多处理多少个包。默认 300，太小 → 频繁重调度 ksoftirqd；太大 → 单次处理太久，影响实时任务响应，还可能加剧 cache miss。
