1. 先把中断这件事说透它到底解决了什么问题很多人学操作系统第一章看进程调度、第二章看内存管理看到中断这块就直接跳过去了觉得不就是打断一下 CPU嘛。但真到写驱动、调 RTOS、优化串口丢包的时候才发现所有问题的根子都在中断上。我自己第一次接触这个概念是在一块 STM32F103 上串口用轮询收数据波特率一上到 115200 就开始丢字节改成中断接收立刻就稳了——那一刻我才算真正理解了操作系统中断存在的意义。这篇文章想聊的是操作系统中断以及和它绑在一起的两个动作关中断和开中断。它适合三类人看正在学计算机操作系统、被中断向量表和 ISR 绕晕的学生写嵌入式驱动、调 STM32 或者国产操作系统下面外设的工程师还有做性能优化、发现系统抖动大却找不到原因的人。关键词会围绕操作系统、中断、关中断、开中断、中断服务函数、中断优化这些展开穿插一些我在 Linux 和裸机两边的实际踩坑记录。我打算按这个顺序讲先说清中断解决的是什么问题再说关中断这个动作到底作用在哪一层然后讲中断控制器怎么和屏蔽机制配合接着落到内核里自旋锁、临界区、底半部这些真实用法最后给两套能直接上手的实操流程和一张排查速查表。1.1 从一次按键说起轮询为什么不够用设想一个最原始的场景你按了一下键盘上的 A 键这个动作需要在屏幕上显示出来。CPU 怎么知道按键发生了最笨的办法是轮询——CPU 不停地去读键盘控制器的一个状态寄存器看第 0 位是不是 1是 1 说明有新按键读出来处理掉然后继续循环读。这个方法逻辑简单但代价惊人假设你把这个循环写成忙等CPU 会被 100% 占满去做看一眼有没有按键这件事其他什么活都干不了。更现实的问题还不是占用率而是时机。如果 CPU 正在执行一个耗时几毫秒的任务中间没空去看状态寄存器而人在这段时间里按了两下键键盘控制器内部只有一个字节的缓冲第二下按键就把第一下的数据覆盖了——这就是丢失事件。轮询的采样频率必须高于事件发生的最快频率一旦事件来得比采样快必丢。中断的思路完全反过来让外设主动喊CPU。键盘控制器检测到按键后拉高一根物理连线送到 CPU 的中断引脚CPU 在当前指令执行完毕、下一条指令取指之前插入一段处理逻辑。**CPU 不需要知道事件什么时候来它只需要事先告诉外设有事就喊我。**这个转变把主动查询变成了被动响应CPU 的利用率从 100% 忙等降到几乎为零同时响应延迟只取决于硬件信号到 CPU 的那几个时钟周期。这个模型放到现代计算机上依然成立。网卡收到一个数据包是中断通知 CPU硬盘完成一次读操作是中断通知 CPU定时器数到点也是中断。整个操作系统的 I/O 子系统本质上就是围绕谁在什么时候打断我搭建起来的。1.2 硬件中断、软件中断和异常三者别混着谈我见过太多人把这三个词混着用结果讨论问题的时候各说各的。它们确实都属于打断当前执行流这件事但来源和处理方式差别很大。硬件中断也叫外中断来自 CPU 外部是真正的物理信号。它经过中断控制器PC 上经典的 8259A、ARM 上的 GIC、MCU 里的 NVIC仲裁后送到 CPU 的中断请求引脚。按键、网卡收包、定时器溢出都属于这一类。硬件中断是异步的——你完全无法预测它下一秒会不会来。软件中断是程序自己主动触发的最典型的就是 x86 的int n指令。它同步、可预测执行到那条指令就一定进中断。早期 Linux 的系统调用就是用int 0x80实现的后来因为性能问题换成了syscall/sysenter指令。软件中断还有另一个用途就是在内核里模拟一次中断来做延迟处理。异常也叫内中断是 CPU 在执行指令过程中自己检测到的异常状况比如除零、访问了非法地址、执行了特权指令。它同样是同步的但来源是 CPU 内部而不是外部设备。ARM 架构里把复位、未定义指令、数据中止这些都归到异常向量里和 IRQ、FIQ 放在同一张表上——这也是为什么热词里stm32调试无法进入中断这类问题的答案经常要先分清你说的是外设 IRQ 还是 HardFault。注意三者的返回值不一样。硬件中断处理完通常回到被打断的那条指令的下一条而异常如缺页处理完后往往要重新执行触发它的那条指令因为异常处理过程可能已经修正了触发条件比如把页面换进来了。这个差别在写异常处理程序时是致命的。1.3 一次中断从触发到返回中间发生了什么不管哪种架构一次完整的中断响应大概都要走这么几步设备发起请求。外设把中断状态寄存器的某一位置 1同时拉高中断线。中断控制器仲裁。如果同时有多个请求控制器根据优先级挑一个把对应的中断号发给 CPU。CPU 保存现场。把当前 PC、状态寄存器、部分通用寄存器压栈。x86 是硬件自动压 EFLAGS、CS、EIPARM Cortex-M 是硬件自动压 xPSR、PC、LR、R12、R3~R0 这八个寄存器。查中断向量表跳转到 ISR。向量表在内存里的固定位置每一项 4 字节32 位系统存的是 ISR 的入口地址。执行中断服务函数。读外设状态、清中断标志、搬数据、通知上层。恢复现场返回。弹栈回到被打断的地方继续跑。第 3 步和第 6 步有个容易忽略的点保存现场这件事本身就是有成本的。Cortex-M3/M4 硬件自动压 8 个寄存器大概 12 个时钟周期如果是带 FPU 的 M4F在中断里用了浮点指令还要额外压 17 个寄存器。在 72MHz 的 F103 上12 个周期约 0.17 微秒看着不多但如果你的中断每秒触发十万次光压栈弹栈就吃掉了 3.4% 的 CPU。这就是中断优化这个词的真正含义——不是让中断更快响应而是让单位时间内中断的总开销降下来。2. 关中断和开中断被误解最深的一对操作2.1 关中断关的是哪一层初学者对关中断最常见的误解是以为关了中断硬件就不产生中断信号了。**并不是。**外设该拉高中断线还是照拉中断控制器的挂起寄存器该置位还是照置只是 CPU 核心不再理它了。真正的动作发生在 CPU 内部的一个状态位。x86 上是 EFLAGS 寄存器的 IF 位Interrupt FlagIF0 表示屏蔽外部可屏蔽中断IF1 表示允许。ARM Cortex-M 上是 PRIMASK 寄存器写 1 表示屏蔽所有可配置优先级的中断HardFault 和 NMI 不受影响。ARM 经典核ARM7/9、Cortex-A上是 CPSR 的 I 位和 F 位分别控制 IRQ 和 FIQ。所以关中断准确的说法是让 CPU 暂时不响应某些中断请求。请求本身还在等你开了中断那些挂起的中断会立刻补上来。这也是为什么关中断时间过长会导致中断丢失——如果某个外设只保留一个挂起位而你在关中断期间事件来了两次第二次就被覆盖了。2.2 从汇编指令到内核 API 的封装链条在裸机上关中断可能就是一行内联汇编/* ARM Cortex-M写 PRIMASK */ __attribute__((always_inline)) static inline void irq_disable(void) { __asm volatile (cpsid i ::: memory); } __attribute__((always_inline)) static inline void irq_enable(void) { __asm volatile (cpsie i ::: memory); }cpsid i就是 CPSID I 的写法把 PRIMASK 置 1cpsie i清零。在 STM32 的工程里CMSIS 已经封装好了就是__disable_irq()和__enable_irq()本质上是同一件事。x86 上对应的就是cli和sti指令。到了 Linux 内核这条链条变成三层最底层是体系结构相关的arch_local_irq_disable()x86 下就是内联cliARM64 下是操作DAIF寄存器的第 7 位。中间层是local_irq_disable()/local_irq_enable()做了一层宏包装。上层是local_irq_save(flags)/local_irq_restore(flags)多了一个保存和恢复的步骤。在 STM32 FreeRTOS 这种组合里链条更长taskENTER_CRITICAL()→portENTER_CRITICAL()→vPortEnterCritical()→__disable_irq()。中间还插了一层uxCriticalNesting的计数用来支持临界区嵌套。2.3 local_irq_save 和 local_irq_disable 的区别坑就在这这两个函数看起来差不多实际用错会导致很难查的 bug。local_irq_disable()是无条件关中断local_irq_enable()是无条件开中断。问题在于上下文。假设你的函数被调用时中断本来就是关着的比如在另一个临界区里面或者在中断处理程序里你调用local_irq_enable()就把本来不该开的中断给打开了。等函数返回外层代码以为中断还关着继续操作共享数据结果被中断打断——数据就烂了。local_irq_save(flags)先把当前的中断状态存到flags里再关中断local_irq_restore(flags)把flags写回去恢复成进来时的样子。这样无论进来时中断是开是关出去时都和进来时一致可以安全嵌套。对应的自旋锁家族也是同样的道理这张表我建议直接背下来API关抢占关中断关软中断典型使用场景spin_lock是否否只在进程上下文访问中断处理程序不碰这把锁spin_lock_bh是否是进程上下文与软中断/tasklet 共享数据spin_lock_irq是是是进程上下文与硬中断共享且确定进来时中断是开的spin_lock_irqsave是是是不确定中断状态绝大多数情况下用这个2.4 关中断窗口能开多大算一笔账关中断本身不是罪关太久才是。到底多久算久这个得算。以 115200 波特率的串口为例一个字节 10 位1 起始 8 数据 1 停止每秒最多传 11520 字节平均每字节间隔1 秒 / 11520 ≈ 86.8 微秒如果你的 MCU 主频 72MHz关中断区间里跑了 500 条指令平均每条指令按 2 个周期算带 Flash 等待周期的保守估计关中断时长500 × 2 / 72,000,000 ≈ 13.9 微秒13.9 微秒远小于 86.8 微秒单字节接收不会丢。但把波特率提到 921600字节间隔变成 10.85 微秒13.9 微秒的关中断就会漏掉整整一个字节的起始位——这就是为什么高速串口不能只靠中断接收必须上 DMA 加空闲中断。再看 CAN 总线500kbps 下最长的扩展帧含填充位大约 130 位左右一帧占用总线时间约 260 微秒用中断接收完全够。但如果总线上跑 1Mbps 且帧很密集中断次数会飙升这时候就要考虑把接收搬到 DMA 或者用 FIFO 加批量中断的方式。经验值一般系统里单次关中断时长控制在10 微秒以内是稳妥的硬实时场景要求控制在1 微秒以内。Linux 内核里有关中断的调试选项能直接把最长的关中断区间报出来这个后面会讲怎么用。3. 中断控制器和屏蔽机制怎么协同工作3.1 从 8259A 到 GIC 再到 NVICCPU 的中断引脚就那么一两根但外设的中断源动辄几十上百个中间的转换器就是中断控制器。PC 时代的 8259A 是级联的两片芯片合起来能管 15 个中断源编号 IRQ0 到 IRQ15IRQ0 给定时器IRQ1 给键盘IRQ4 给串口一。中断号直接写死谁插在哪根线上就是哪个号特别不灵活。后来被 APIC 取代可以支持多核、可以动态分配向量。ARM 服务器和手机用 GICGeneric Interrupt Controller分成 Distributor 和 CPU Interface 两部分。Distributor 负责收集所有中断源、根据优先级排队、决定发给哪个 CPU 核CPU Interface 负责和具体核心对接处理应答和结束。常见的有 GICv2最多 8 核、GICv3支持上千核用 GICR 附加寄存器、GICv4加上了虚拟化直接注入。这也是为什么麒麟操作系统银河麒麟服务器操作系统这类国产系统在 ARM 服务器上跑的时候中断亲和性配置和 x86 完全不一样——你得去/proc/irq/n/smp_affinity里改 CPU 掩码。MCU 这边简单很多Cortex-M 用的 NVIC 直接集成在核里最多 240 个外部中断每个中断有独立可编程的优先级寄存器。再往上一点TI 的 C2000 系列有个 PIE 模块Peripheral Interrupt Expansion把 96 个外设中断源分组复用到 CPU 的 12 条中断线上每组 8 个源共用一套使能寄存器——这就是热词里pie中断的由来本质上是中断源比 CPU 中断线多的时候的一种扩展方案。3.2 屏蔽位其实有三个层级很多人以为关中断就一个开关实际上屏蔽发生在三个不同的地方**第一层外设自己的使能位。**比如 USART 的 CR1 寄存器里的 RXNEIE 位不置 1 的话接收寄存器非空也不会发出中断请求。这一层决定了这个事件要不要产生中断。**第二层中断控制器的屏蔽位。**NVIC 的 ISER 寄存器对应每个中断的使能位GIC 也有对应的 set-enable 寄存器。这一层决定了产生的中断请求要不要送给 CPU。注意这一层通常有个挂起逻辑即使你在控制器层面屏蔽了如果事件已经发生挂起位会置 1等你解除屏蔽立刻补一次。**第三层CPU 核心的全局开关。**就是前面说的 PRIMASK / IF 位 / DAIF。这一层是关中断这个词最常指的东西。理解这三层之后很多迷惑就解开了。比如我在中断里关了中断为什么另一个中断还能进来——因为你只操作了第三层如果那个中断是 NMI 或者 HardFault它根本不受 PRIMASK 影响。再比如为什么我清不掉中断标志——可能是外设那一层的使能位没关事件还在持续产生。3.3 优先级与嵌套什么时候高优先级能插队Cortex-M 的 NVIC 支持中断嵌套但前提是你允许嵌套。具体规则是当前正在执行的中断优先级是 P一个新中断请求的优先级是 Q只有当 Q 的数值小于 P数值越小优先级越高时才会抢占。这里有个隐藏条件如果 ISR 里执行了__disable_irq()那么无论新中断优先级多高都不会抢占直到__enable_irq()或者 ISR 返回。x86 上情况不同。传统的 PIC 模式下CPU 响应中断时会自动清 IF 位也就是说默认不嵌套如果要在 ISR 里允许被更高优先级中断打断得手动执行sti。不过现代的 x86 内核普遍采用中断处理尽量短的策略不在 ISR 里做嵌套而是把耗时工作丢给下半部。ARM 的 GIC 有个 Group 的概念GICv3 里把中断分成 Group 0对应 FIQ给安全世界/EL3和 Group 1对应 IRQ给普通世界。Linux 在 ARM64 上跑的时候内核态通常把 DAIF 的 I 位关掉而不是 F 位这样 NMI 类的调试中断还能进来方便定位死锁。4. 内核里的真实用法自旋锁、临界区和底半部4.1 自旋锁为什么要和关中断捆绑使用自旋锁解决的场景是两个 CPU 核同时访问同一块数据或者一个 CPU 核上的进程上下文和中断上下文访问同一块数据。前一种情况用普通自旋锁就够了因为它保证了同一时刻只有一个核在临界区里。后一种情况麻烦得多。设想这个序列进程 A 拿到了自旋锁进入临界区开始修改共享链表。定时器中断在这颗 CPU 上触发了ISR 也要访问同一个链表。ISR 尝试拿锁发现锁被持有于是自旋等待。但持锁的是被自己打断的进程 A进程 A 在 ISR 返回前根本没法继续执行。死锁。这不是锁的问题是设计问题你必须保证中断处理程序不会在持锁期间进来。做法就是在拿锁的同时关掉本地中断让中断在锁释放之后才可能发生。反过来说如果中断处理程序也要拿这把锁那么关中断的窗口就覆盖了整个临界区。特别注意关中断只能关本 CPU的中断。另一个 CPU 核照样能来抢锁所以自旋锁本身还得有原子操作做基础ARM 上是 LDREX/STREXx86 上是 LOCK 前缀指令两者缺一不可。4.2 上半部和下半部为什么中断处理程序要短Linux 把中断处理拆成两半这个设计不是拍脑袋定的是被中断上下文的三条限制逼出来的**中断上下文不能睡眠。**它没有 task_struct调度器不认识它一旦睡下去就永远醒不来。这意味着不能调用任何可能阻塞的函数不能拿互斥锁不能访问可能触发缺页的用户空间指针。**中断处理期间本 CPU 上的中断是关的。**至少同优先级的中断进不来处理太久会导致丢事件和响应延迟。**中断上下文不可重入。**同一中断线在正在处理时默认会被屏蔽不需要考虑自己重入。所以上半部硬中断处理函数只做最紧急的事读走硬件里的数据、清中断标志、把数据塞到某个缓冲区然后触发下半部。真正耗时的解析、协议处理、唤醒用户进程都放到下半部去做。下半部有三种主流机制选择依据是能不能睡眠机制运行上下文能否睡眠适用场景软中断 softirq下半部上下文否网络收发、定时器等性能敏感路径静态分配tasklet下半部上下文否驱动的延迟处理动态分配同一 tasklet 不会并发工作队列 workqueue内核线程是需要睡眠、需要拿互斥锁、耗时较长的处理线程化中断 threaded irq内核线程是现代驱动首选request_threaded_irq一行搞定线程化中断这几年越来越主流因为它把上半部必须极短这个约束放宽了——耗时代码直接跑在内核线程里可以睡眠可以被调度还能给这个线程设优先级和 CPU 亲和性。代价是多一次上下文切换和唤醒延迟一般几十微秒量级对绝大多数外设都够用。市面上一些现代的操作系统比如鸿蒙系统在面向设备的版本里也采用了类似的线程化处理思路把中断处理放到可调度的任务里方便做优先级管理和功耗控制。4.3 抢占、软中断和关中断的边界还有个概念经常和关中断混淆抢占禁止preempt_disable。关中断影响的是外部事件能不能打断我抢占禁止影响的是调度器能不能把我换下去。在 Linux 上一个进程被换出去的时机通常是在中断返回时或者显式调用schedule()时所以如果中断被关了抢占实际上也间接被禁了。反过来只调preempt_disable()不关中断中断还是会进来只是中断返回时不会触发调度。在spin_lock的实现里这两件事都做了既关抢占又在某些变体里关中断。所以在临界区里调用schedule()会直接报 scheduling while atomic这是内核主动帮你抓 bug。RTOS 那边逻辑更直白。FreeRTOS 在进入临界区时调vPortEnterCritical()它会先__disable_irq()然后操作计数变量最后如果计数减到 0 就__enable_irq()。所以 FreeRTOS 的taskENTER_CRITICAL()是真的把中断全关了只留 NMI 和 HardFault。这也是为什么在 FreeRTOS 里做实时性要求高的采集要特别小心临界区的长度——它直接决定了你的最大中断延迟。5. 动手实操Linux 与 STM32 两条路线5.1 Linux 侧从 /proc/interrupts 开始观察任何中断问题的排查第一步都是看现场。Linux 上最直接的工具是/proc/interrupts$ cat /proc/interrupts CPU0 CPU1 0: 23 0 IO-APIC 2-edge timer 1: 4 0 IO-APIC 1-edge i8042 8: 1 0 IO-APIC 8-edge rtc0 16: 8723 0 IO-APIC 16-fasteoi i801_smbus 24: 1245831 0 PCI-MSI 524288-edge eth0-rx-0输出里每一列的含义要搞清楚最左边是中断号中间是各 CPU 上的触发次数然后是控制器类型和触发方式最后是注册这个中断的驱动名。几个关键信号计数完全不涨中断根本没触发。先查外设使能位、引脚复用配置、时钟是不是没开。计数涨得飞快可能是电平触发的中断标志没清导致重复进入。这时候要进 ISR 看清除顺序。全挤在一个 CPU 上中断亲和性没配好可以写/proc/irq/24/smp_affinity把负载分散开。软中断看/proc/softirqs能看到 NET_RX、NET_TX、TIMER、RCU 这些的分布。如果 NET_RX 数字极高而且集中在 CPU0通常说明网卡用了单队列或者 RPS 没开。5.2 写一个能测关中断延迟的内核模块光看计数器不够得能量化关中断的时长。Linux 内核自带了 irqsoff tracer但如果你想在驱动里自己测可以这么写#include linux/module.h #include linux/kernel.h #include linux/interrupt.h #include linux/ktime.h static unsigned long flags; static ktime_t t_start, t_end; static int __init irq_lat_demo_init(void) { s64 delta_ns; /* 记录进入关中断前的时间戳同时关中断并保存原状态 */ t_start ktime_get(); local_irq_save(flags); /* 这里放你要保护的临界区代码 * 注意中间绝对不能调用可能睡眠的函数 */ udelay(50); t_end ktime_get(); local_irq_restore(flags); delta_ns ktime_to_ns(ktime_sub(t_end, t_start)); pr_info(irq disabled window %lld ns (%lld us)\n, delta_ns, delta_ns / 1000); return 0; } static void __exit irq_lat_demo_exit(void) { pr_info(irq_lat_demo unloaded\n); } module_init(irq_lat_demo_init); module_exit(irq_lat_demo_exit); MODULE_LICENSE(GPL);配套的 Makefile 是标准写法obj-m irq_lat_demo.o KDIR : /lib/modules/$(shell uname -r)/build all: $(MAKE) -C $(KDIR) M$(PWD) modules clean: $(MAKE) -C $(KDIR) M$(PWD) clean编译加载make sudo insmod irq_lat_demo.ko sudo dmesg | tail -5你会看到类似irq disabled window 52841 ns (52 us)的输出。注意udelay(50)理论上是 50 微秒实测出来 52 微秒多出来的部分是ktime_get()本身的开销和函数调用。这说明测量工具自己也会吃掉时间做精确测量时要把这部分扣掉或者用更轻量的时间源。提示在打开了CONFIG_PREEMPT或者CONFIG_PREEMPT_RT的内核上local_irq_save未必真的关硬件中断。PREEMPT_RT 把大部分中断转成了内核线程local_irq_disable变成了只关一个软件标志。所以这套测法在 RT 内核上测出来的数字会小得离谱别被误导。5.3 STM32 侧NVIC 优先级分组与开关中断裸机这边先把优先级分组确定下来。Cortex-M 的优先级寄存器有 8 位但 ST 一般只实现了高 4 位所以有 5 种分组方式/* 4 位全部作为抢占优先级0~15可嵌套 */ NVIC_SetPriorityGrouping(NVIC_PriorityGroup_4); /* 2 位抢占 2 位子优先级 */ NVIC_SetPriorityGrouping(NVIC_PriorityGroup_2);抢占优先级决定能不能嵌套子优先级只在同时挂起时决定先响应谁不影响嵌套。配置一个串口中断/* 使能 USART1 时钟 */ RCC-APB2ENR | RCC_APB2ENR_USART1EN; /* 使能接收中断 */ USART1-CR1 | USART_CR1_RXNEIE; /* 设置优先级并开启 NVIC 通道 */ NVIC_SetPriority(USART1_IRQn, 5); NVIC_EnableIRQ(USART1_IRQn); /* 全局开中断 */ __enable_irq();中断服务函数里关键是先判断标志、再读数据、最后清标志顺序错了会导致重复进入void USART1_IRQHandler(void) { if (USART1-SR USART_SR_RXNE) { uint8_t ch (uint8_t)(USART1-DR 0xFF); ringbuf_push(rx_buf, ch); } if (USART1-SR USART_SR_ORE) { /* 溢出错误读 SR 再读 DR 即可清除 */ (void)USART1-SR; (void)USART1-DR; } }这里USART1-SR的判断其实隐含了清标志的动作——读 SR 再读 DR 就自动清了 RXNE。如果你用 HAL 库HAL_UART_IRQHandler已经把这一套做完了但 HAL 的分支判断很多执行时间比手写的裸寄存器版本长不少。对时间敏感的场景我一般会把 HAL 的中断处理整个替换成裸寄存器版本实测在 72MHz 下能从 1.8 微秒降到 0.6 微秒左右。还有个进阶技巧是 BASEPRI。它的作用是屏蔽优先级数值大于等于某个值的中断比 PRIMASK 更细/* 只屏蔽优先级 5 及以下数值更大优先级更低的中断 */ __set_BASEPRI(5 (8 - __NVIC_PRIO_BITS)); /* 解除 */ __set_BASEPRI(0);FreeRTOS 的临界区在 Cortex-M 上用的就是 BASEPRI它会把你配置的configMAX_SYSCALL_INTERRUPT_PRIORITY写进去这样高优先级的硬件中断数值小于这个阈值不会被屏蔽保证了紧急中断的实时性。这个设计很巧妙——用一层优先级门槛换来了既保护临界区、又不牺牲紧急中断的效果。5.4 用 trace 定位关中断过长的元凶系统卡顿、串口丢包、音频爆音如果怀疑是关中断太久Linux 上有现成的工具链# 查看当前可用的 tracer sudo cat /sys/kernel/debug/tracing/available_tracers # 开启 irqsoff tracer echo irqsoff | sudo tee /sys/kernel/debug/tracing/current_tracer echo 1 | sudo tee /sys/kernel/debug/tracing/tracing_on # 跑一段业务然后关掉 echo 0 | sudo tee /sys/kernel/debug/tracing/tracing_on # 看结果 sudo cat /sys/kernel/debug/tracing/trace输出会直接告诉你最终延迟是多少微秒以及从关中断到开中断之间调用栈长什么样。下面还会有一个max_latency文件记录历史最大延迟。我在一台 ARM 服务器上排查网络抖动时就是用这个方法定位到某个驱动在 ISR 里做了一次 200 微秒的memcpy把它挪到工作队列之后最大延迟从 210 微秒降到 8 微秒。STM32 那侧没有这么强的工具但有替代方案用一个空闲的定时器做微秒级计时在中断入口和出口分别打时间戳存到环形缓冲区跑一段时间再 dump 出来分析。更省事的办法是用 GPIO 翻转配合逻辑分析仪或者示波器进 ISR 拉高出 ISR 拉低直接看波形占空比。这个方法虽然原始但最直观测抖动也最准。6. 常见问题与排查速查表6.1 典型症状对照表下面这张表是我这些年攒下来的经验按症状反查原因能省不少时间症状最可能的原因排查动作中断计数完全不涨外设使能位没置、时钟没开、引脚复用错了用示波器量中断引脚有没有电平变化逐级往上游查中断计数涨得异常快中断标志没清干净或者电平触发持续有效检查清标志的时机边沿/电平触发方式配的对不对进了中断就死机栈溢出、访问了非法地址、在 ISR 里调用阻塞函数看 HardFault 的 LR 和栈帧检查 ISR 调用链串口高波特率丢数据关中断窗口比字节间隔长改成 DMA 空闲中断或缩短临界区系统卡顿但有中断在跑关中断时间过长或者软中断风暴用 irqsoff tracer 定位最长的关中断区间中断优先级改了没效果优先级分组没配对或者用了错误的位宽确认NVIC_PriorityGroup和优先级数值范围多核负载不均中断全落在 CPU0配smp_affinity或开启 RPS/RFS中断延迟随负载增长中断被关在了某个长临界区外面检查spin_lock_irqsave的持锁时间6.2 我踩过的几个坑第一个坑是在中断里用了打印。裸机上用printf如果底层是阻塞式串口发送一个 20 字节的字符串在 115200 下要 1.7 毫秒如果你的中断每秒来几千次系统直接瘫。后来全改成往环形缓冲区里塞数据主循环再打印问题解决。Linux 上一个类似的坑是在 ISR 里用printk虽然printk不睡眠但输出到串口控制台同样会阻塞很久内核有printk限流机制但最好还是换成printk_deferred或者干脆不打。第二个坑是用local_irq_enable而不是local_irq_restore。当时写的驱动在处理流程里调了local_irq_disable()处理完调local_irq_enable()。测试的时候一切正常直到把这个函数被另一个也在临界区的路径调用立刻出现随机崩溃。改法很简单全部换成local_irq_save(flags)/local_irq_restore(flags)保存和恢复成对出现。第三个坑是在 ISR 里操作共享数据但没加锁。这个错误的隐藏性很强因为大部分时候看着是好的——直到某次中断恰好落在主循环修改链表的中间那一刻指针就飞了。这类 bug 复现率极低但后果严重正确做法是把共享数据放进临界区或者用无锁的单生产者单消费者环形缓冲区。第四个坑是关中断期间调用了带内存分配的函数。哪怕只是一个看起来人畜无害的malloc它内部可能持有自己的锁可能触发页面分配可能在慢路径里睡眠。一旦睡眠关中断就变成了永久关中断整个 CPU 就废了。我现在写代码的习惯是任何进临界区之前先在心里过一遍这块代码会不会睡、会不会分配内存、会不会调外部模块。还有一个不算坑但值得说的点不是所有场景都需要关中断。如果共享数据只有一个写者中断和一个读者主循环而读者只关心数据的完整性可以用双缓冲或者序号校验那完全可以不关中断用无锁方式解决。关中断是个重武器能不用就不用用之前先想清楚有没有更轻的方案。对于国产操作系统生态我看到的一个变化是越来越多的实时场景开始用 Linux 加 RT 补丁或者用国内厂商做的实时内核。这类内核对关中断的处理和标准内核差别不小很多操作变成了对软件状态的操作测出来的延迟数字漂亮但语义变了。做实时性评估的时候光看关中断的耗时数字是不够的还要看最坏情况下的调度延迟和中断线程的唤醒时间这两个才是决定端到端响应的关键指标。我在一个数据采集项目里就吃过这个亏原先按最长关中断 5 微秒估算没问题实测丢包才发现中断线程被一个低优先级任务压了 300 微秒后来把中断线程优先级提到最高才解决。