ksoftirqd 持续高 CPU 占用本质是软中断积压，主因包括：1. 网络流量突增或异常包致 NET_RX/NET_TX 飙升；2. 存储 I/O 压力大或驱动异常引发 BLOCK 软中断堆积；3. RCU 回调积压；4. 硬件中断风暴间接诱发。
Linux 中 ksoftirqd 进程持续高 CPU 占用，本质是内核软中断（softirq）处理积压，常见于网络、块设备、定时器等子系统负载过重或异常。关键不是进程本身“有问题”，而是它在拼命消化堆积的软中断任务。
网络流量突增或异常包导致 NET_RX/NET_TX 软中断飙升
这是最常见原因。当网卡收包速率远超协议栈处理能力（如突发 DDoS、大量小包、TCP 乱序重传加剧）、或存在驱动兼容性问题时，NET_RX 软中断会持续触发，ksoftirqd/N 被频繁唤醒并满载。
- 用
cat /proc/softirqs查看各 CPU 上NET_RX和NET_TX计数增长是否远高于其他项 - 检查
ethtool -S ethX中rx_missed_errors、rx_over_errors是否上升——说明网卡已丢包，软中断仍在徒劳处理 - 临时缓解可调大网卡 ring buffer：
ethtool -G ethX rx 4096 tx 4096；长期需优化应用层收发逻辑或升级驱动
存储 I/O 压力大或驱动异常引发 BLOCK 软中断堆积
当磁盘响应慢（如高延迟 NVMe、饱和 HDD、RAID 卡故障）、或使用了不稳定的 SCSI/ATA 驱动时，I/O 完成回调会触发 BLOCK 软中断。若完成队列积压，ksoftirqd 就会持续忙于处理完成事件。
- 观察
/proc/softirqs中BLOCK和BLOCK_IOPOLL的值是否显著偏高 - 结合
iostat -x 1看%util是否长期 100%、await是否异常升高 - 检查 dmesg 是否有 “ata/N: failed command”、“nvme N: I/O timeout” 类错误；尝试更新固件或更换 I/O 调度器（如
mq-deadline替代bfq）
RCU 回调积压（RCU_SOFTIRQ）引发持续软中断调度
RCU（Read-Copy-Update）是内核关键同步机制。当大量内核对象（如 socket、task_struct、page）被快速创建销毁，或存在 RCU callback 延迟执行（如在关中断上下文停留过久），会导致 RCU_SOFTIRQ 积压，ksoftirqd 不断被拉起处理回调。
- 运行
cat /proc/sys/kernel/rcu_normal或rcu_pending（需开启 CONFIG_RCU_PERF）确认 RCU 压力 -
perf record -e 'irq:softirq_entry' -g -- sleep 5后用perf report查看软中断入口热点，常看到rcu_core、__rcu_reclaim占比高 - 排查是否启用了低效模块（如某些旧版 eBPF 程序、netfilter conntrack 高并发场景），或内核版本存在已知 RCU bug（如 4.19 早期某些 commit）
硬件中断风暴（IRQ storm）间接诱发软中断过载
某些异常硬件行为（如网卡 DMA 错误、PCIe 链路不稳定、老旧 USB 控制器）会导致同一 IRQ 号被反复触发，每次硬中断都会排队对应软中断。即使单次软中断处理快，高频触发仍让 ksoftirqd 无法喘息。
- 用
cat /proc/interrupts观察某 CPU 上特定 IRQ 计数是否秒级暴涨（尤其对比其他 CPU） - 检查
dmesg | grep -i "error\|warn\|pci\|dma"是否有硬件报错；尝试禁用可疑设备（如echo 0 > /sys/bus/pci/devices/.../enable）验证 - 对支持 MSI-X 的设备，启用多队列并绑定到不同 CPU（
echo cpu_mask > /sys/class/net/ethX/device/msi_irqs/...），避免单 CPU 被 IRQ 打爆
