排查麒麟系统硬件响应延迟或cpu单核打满问题，须按序执行四步：先用cat /proc/interrupts查看各cpu中断分布，再用lsirq -v解析设备与irq映射，接着查/proc/irq/n/smp_affinity_list确认亲和性设置，最后用trace-cmd record -e irq:irq_handler_entry -e irq:irq_handler_exit抓取单次中断处理耗时。
排查麒麟系统硬件响应延迟或CPU单核打满问题，必须确认中断是否集中触发、绑定是否失当、单次处理是否超时：先用cat /proc/interrupts看各CPU中断分布，再用lsirq解析设备与IRQ映射，查smp_affinity_list确认亲和性设置，最后用trace-cmd抓中断处理耗时。
查看各CPU中断触发次数分布
执行cat /proc/interrupts，这是内核实时维护的只读文件，反映每个CPU上各类中断（IRQ）自启动以来的触发次数。
重点盯最后一列设备名（如eth0、nvme0n1、i915）和对应CPU列数值——如果某行某列（比如CPU0）每秒涨几百上千，而其他列几乎不动，说明该中断被钉死在单核上“堵车”。
看到IR-PCI-MSI或IR-IO-APIC前缀，是虚拟化环境启用中断重映射的标志，此时IRQ编号已与物理引脚解耦，别按传统编号理解。
数值为0不等于设备没工作——网卡若启用NAPI或轮询模式（ethtool -C eth0 rx off），中断计数归零但流量照常。
解析设备与IRQ的映射关系
方法一：使用lsirq工具（推荐）
第一步：确认工具是否存在：which lsirq。未安装则按系统类型执行：
Ubuntu/Debian系：sudo apt install linux-tools-common
RHEL/CentOS系：sudo yum install kernel-tools
第二步：运行sudo lsirq -v，它会把/proc/interrupts原始数据解析成设备名、驱动名、绑定CPU列表、中断类型等可读字段，比手动grep清晰十倍。
快速筛出网卡或NVMe设备：sudo lsirq | grep -i "eth0\|nvme"，直接定位关键硬件的IRQ归属。
注意：必须加sudo，否则无法读取/proc/irq/*下的权限受限文件；不加-v参数仅显示简表，丢失关键字段。
检查中断CPU亲和性设置
① 找出目标设备对应的IRQ号。例如查eth0：grep eth0 /proc/interrupts | awk '{print $1}'
② 用该IRQ号查其当前绑定的CPU列表：cat /proc/irq/$(grep eth0 /proc/interrupts | awk '{print $1}')/smp_affinity_list
输出是十进制CPU编号（如0,2,3），人眼可读；若显示为空或报错Operation not permitted，说明该IRQ被固件锁定（常见于BMC、老RAID卡），不可修改。
③ 验证是否被irqbalance接管——对比cat /proc/irq/N/effective_affinity和smp_affinity_list，若两者不一致，说明后台服务正在覆盖你的手动设置。
别直接写smp_affinity（十六进制掩码）——x86和ARM位宽不同，写错会导致中断完全不触发。
抓取单次中断处理耗时
方法一：用trace-cmd抓纳秒级handler生命周期
先确认内核支持：grep CONFIG_IRQSOFF_TRACER /boot/config-$(uname -r)，返回y或m才可继续。
安装trace-cmd（如未预装）：sudo apt install linux-tools-common
录制10秒中断事件：sudo trace-cmd record -e irq:irq_handler_entry -e irq:irq_handler_exit -M 10
生成可读报告：sudo trace-cmd report，重点关注handler_entry到handler_exit之间的时间差，超过100μs即属异常。
