OS通过何种机制判定I/O操作已完成执行？

OS下发磁盘读请求之后，不会空等硬件返回，会先把等待该IO的进程切到阻塞状态，把请求封装成块IO请求丢给存储驱动的下发队列，转头就调度其他就绪进程占用CPU跑。硬件完成操作后通知OS的机制，主流就两类，对应不同的使用场景：

1. 硬件中断（通用场景的默认实现） #

这是民用、企业级通用存储场景用了几十年的标准方案，流程没有什么玄乎的：

• 磁盘控制器拿到OS下发的读请求后，全程独立操作：机械盘就驱动磁头寻道、读对应扇区数据，固态盘就读对应闪存页的数据，硬件自己做ECC纠错校验，确认数据没问题之后，通过*DMA（直接内存访问）*控制器把数据直接搬到OS提前预留好的内核内存缓冲区里，整个过程完全不需要CPU参与。
• 等数据全部写入内存、校验完成，控制器就会通过主板的中断控制器给CPU发一个硬件中断信号，带上本次完成的IO请求的唯一标识。
• CPU收到中断信号后，会立刻暂停当前正在执行的任务，跳转到启动时就注册好的磁盘中断处理函数执行：
  • 中断上下文里只做最紧急的事：核对完成的IO请求编号，标记对应块IO结构的完成状态，记录有没有介质读错误，立刻清掉控制器的中断标志位避免重复触发中断。
  • 剩下耗时的收尾工作（比如把数据从内核缓冲区拷贝到用户进程的地址空间、唤醒之前阻塞等这个IO的进程）会扔给软中断/工作队列延后执行，避免关中断时间太长，影响其他硬件的中断响应。
• 现在的NVMe固态、多队列块层用的MSI-X消息中断还做了优化：不用多个设备共享一根中断线，每个IO队列可以绑定单独的中断号，直接投递到对应CPU核心，省去跨核调度的开销，中断延迟比老的AHCI控制器低很多。

2. 主动轮询（低延迟高性能场景专用） #

中断机制本身有固有开销：中断触发时的上下文切换、打断CPU正在跑的任务导致的CPU缓存失效，在对延迟极度敏感、IOPS极高的场景（比如高端数据库裸设备部署、SPDK这类用户态高性能存储框架）里，会直接放弃中断，用轮询模式做完成通知：

• 这种模式下OS（或者用户态存储栈）下发IO请求后，不会把等待的进程切到阻塞态，而是会绑定一个CPU核，不停主动读取磁盘控制器的完成队列寄存器，检查对应IO请求的完成标志位有没有被硬件置位。
• 一旦查到标志位置位，就直接在当前上下文做数据校验、数据交付的逻辑，完全没有中断的切换开销，端到端IO延迟可以压到微秒级。缺点是轮询的CPU核会一直处于忙等状态，不能跑其他任务，只有在CPU核数足够、延迟优先级远高于CPU利用率的场景才会用。

几个常见的认知误区 #

• 不是DMA传输完成就等于IO完成：DMA只是硬件把数据搬到内存的过程，之后控制器还要做数据校验，遇到坏块还要先做重读、坏块重映射，全部确认没问题才会发完成通知，要是重试失败就会给OS返回IO错误。
• 如果读请求命中了OS的页缓存，根本不会下发到磁盘硬件，直接从内存返回数据，完全不涉及上述硬件通知流程。
• 读IO和写IO的完成语义不一样：如果开了磁盘自身的写缓存，写请求报完成的时候数据可能还在磁盘的缓存里没落到介质；但读请求只要报完成，数据一定已经放到OS可访问的内存里，不会出现访问不到的问题。

内容的提问来源于stack exchange，提问作者Georgi Popov