设备完成、通知到达、驱动处理和业务线程运行是不同阶段；中断不是载荷，也不是最终业务完成。

通知与状态是不同对象

设备可以把完成状态写入约定结构，再提示软件处理。通知本身通常只表达有事件或需要检查，具体哪项任务、多少字节、是否错误仍需查看相应状态。

设备执行 -> 完成状态可见 -> 通知/轮询发现 -> 驱动处理
                                                |
                                           唤醒/回调
                                                |
                                           线程调度
                                                |
                                           业务继续

图是原创状态分解，不保证任意设备实现相同顺序或同样的数据结构。

轮询与中断改变发现方式

中断让软件在事件提示后处理；轮询由软件主动检查状态。它们对发现延迟、CPU 消耗和批处理机会产生不同影响。没有统一的“中断一定更快”或“轮询一定更好”。

某些路径组合两种机制。Linux 网络中的 NAPI 提供相关例子，但不能把网络处理规则套到所有存储设备。

一次通知可能覆盖多个任务

驱动可能批量处理多个完成，设备也可能在一定条件下合并通知。因此中断次数不是业务请求次数，减少中断不一定表示工作减少，增加中断也不一定说明故障。

MSI/MSI-X 能力与使用方式见 Linux MSI 指南。向量、队列和 CPU 之间如何分配取决于设备与驱动，不能凭向量数量推导应用并行度。

完成处理可以成为新的等待点

设备很快，软件仍需获得处理时间。忙于其他工作、线程配额、CPU 位置和队列积累可能使通知之后的处理变慢。业务观察到的长时延未必全部发生在设备内部。

原创场景：相同 I/O 负载下，设备统计接近基线，应用等待增加，而某处理 CPU 持续忙。这个组合支持软件完成路径受限的假设，仍需排除观察窗口和对象错配。

超时不等于硬件已停止

超时后可能仍有迟到的完成或 DMA。若软件复用任务编号、缓冲区或状态对象，需要协议保证旧任务不会破坏新任务。设备重置与资源回收必须按接口要求配合。

本篇解释这种风险，不提供设备重置脚本。生产现场不能为了验证一个假设直接重启共享控制器。

证据应该记录哪一段

有价值的观察区分设备执行时间、发现完成的时间、驱动处理时间以及应用重新运行的时间。只记录开始和最终返回，只能得到总时间，不能凭空拆出各段。

Linux PSI 可提供资源等待背景，但不能直接替代逐阶段的时序证据。采样、跟踪与断点的区别见 远程调试机制。

服务器知识库 · 系统架构 · 数据路径 · 测试验收 · 工程参考

公开资料核对：2026-10-07。文档类型：Explanation。逻辑图、场景推演与报告模板为原创，不代表实测结果、厂商内部设计或公司制度；操作仅限获授权的目标和环境。