Linux lsirq 的总计数与各CPU计数怎样对应

我第一次用 lsirq 看网卡中断时，最容易误读的是把 TOTAL 当成某一个 CPU 的计数。它实际表示当前输入里、当前筛选集合中的各 CPU 计数之和；默认覆盖全部 CPU，使用 -C 后只累加指定 CPU。换句话说，lsirq 是把 /proc/interrupts 的横向数据压成每个 IRQ 一行，而不是又维护了一套独立计数。

官方地址：https://www.man7.org/linux/man-pages/man1/lsirq.1.html

lsirq 的 TOTAL 为什么能和 CPU 分列对上

/proc/interrupts 的表头通常包含 CPU0、CPU1 等列，每一行对应一个 IRQ。比如某一行的计数是 120、80、0，那么这一行的总计数就是 200。util-linux 的读取逻辑会先数出输入表头里的 CPU 列，再逐列解析每个 IRQ；未被筛选的计数累加到该行的 total，同时累加到 CPU 汇总。

lsirq 默认列是 IRQ、TOTAL、NAME，所以你看不到每个 CPU 的原始分列。需要回到源数据对照时，先保存同一时刻的输入，再进行人工求和：

# 读取内核中断表；每行的 CPU 分列是 lsirq 汇总的输入
sed -n '1,12p' /proc/interrupts

# 显式固定 lsirq 的脚本输出列，避免默认列未来变化
lsirq --output IRQ,TOTAL,NAME --sort TOTAL

这里的数字是启动以来的累计值，不是采样窗口内的速率。两个命令分开读取时，系统可能已经产生新中断，因此出现几个计数的差异并不奇怪。要做严谨对照，应使用 lsirq --input 读取同一份采集文件；手册也提醒默认输出可能变化，脚本应显式指定列。

-C 选择 CPU 后，TOTAL 为什么会变化

-C 是理解这个问题的关键。假设 IRQ 42 的三个 CPU 计数为 120、80、0：

因此，-C 得到的总数不是“原始总数的另一种显示”，而是按子集重新汇总的结果。排查某个 IRQ 是否集中在 CPU1 时，可以先看全局，再看子集：

图中的“选中集合”是用户态统计边界；它不会改变 IRQ 的路由，也不会把中断迁移到某个 CPU。真正决定允许哪些 CPU 处理 IRQ 的线索在 /proc/irq//smp_affinity 或 smp_affinity_list。这两个问题要分开：-C 负责“算哪些”，亲和性负责“可能在哪些 CPU 上处理”。

用固定输出做一次可复查的排查

我更愿意把排查分成“来源、汇总、路由”三层。先确认输入是否有目标 IRQ 和 CPU 列；再用固定列名输出；最后查看亲和性与设备队列。需要机器可读结果时可使用 JSON，但不要依赖默认字段顺序：

 /tmp/lsirq.json

# 查看 IRQ 允许的 CPU 列表；这里只读配置线索，不改动系统
cat /proc/irq/42/smp_affinity_list

另外，/proc/interrupts 的总行还可能包含未编号的架构相关中断；它们不会都以独立的编号行出现。不要拿某些可见 IRQ 行简单相加后，要求它必然等于系统总行。

常见问题与边界

lsirq 的 TOTAL 是实时速率吗？

不是。它是从输入中读到的累计计数；要看速率，需要在两个采样点计算差值并除以时间间隔。

为什么两个命令读到的 TOTAL 不完全一致？

中断计数会继续增长，且两次读取不是同一快照。保存输入文件后再用 --input，才能把比较窗口固定下来。

-C 能改变 IRQ 的 CPU 亲和性吗？

不能。它只改变本次统计纳入的 CPU；修改亲和性属于另一条配置路径，生产环境应先确认设备和中断模型再调整。

记住一条就够了：先把 lsirq TOTAL 解释成“选定 CPU 集合的行内求和”，再用 smp_affinity 解释“为什么计数会集中”。这样看出来的数字，才不会把统计边界和调度边界混在一起。