dispatch_io可以很好地解决哪些本地存储I/O模式？

Question

我是Grand Central Dispatch的忠实粉丝,我最近一直在关注这一dispatch_io_*系列的电话.很容易看出这个API如何对网络I/O(慢速,高延迟)有用.也就是说,存在dispatch_io_create_with_path某种意味着在本地文件系统上使用.(是的,我知道路径也可以指向远程网络文件系统上的资源,但无论如何......)在使用它时,我发现dispatch_io_*与使用简单的阻塞相比,使用似乎带来了相当大的开销I/O调用(read,write,等).这种减速似乎主要来自内核同步原语,用作块在队列之间来回编组.在我一直在玩的示例工作负载中(非常多的I/O界限),减速可能差到10次.首先,它似乎dispatch_io永远不会成为chatty(小颗粒)I/O的胜利.

我认为,在具有单个本地物理存储卷的单个机器的常见情况下,I/O请求将在设备级别有效地序列化.从那里,我发现自己有这两个想法:

• 如果您的工作负载受CPU限制,那么根据定义,您可以比处理数据更快地读取/写入数据.
• 如果您的工作负载受I/O限制(在这种情况下 - 一个本地物理卷),dispatch_io则无法使您的磁盘更快地为您提供数据.

从那里开始,我认为这个API的最佳位置可能就在中间 - 这是一个在CPU受限和I/O限制之间徘徊的工作量,但此时我有点想到自己陷入困境,所以我想我会问StackOverflow.

我将接受第一个回答,它描述了具有这些前提条件的"真实世界"工作流程(即单机,单个本地物理磁盘),使用它们dispatch_io可以显着提高性能.

Answer 1

来自本地文件系统的调度I/O的主要用例是较大文件的异步IO,或者同时读取/写入的许多文件(特别是如果可以递增地处理文件的内容).

来自本地文件系统的调度I/O针对延迟的吞吐量进行了优化(例如,它在实际IO系统调用之前执行分块和建议读取,以优化通过内核和驱动程序的IO路径上的流水线和吞吐量).

鉴于在后台线程上异步执行IO系统调用,调度IO将永远不会超过使用阻塞系统调用执行的微小文件IO的延迟,特别是在没有其他IO活动正在进行时.

来自WWDC11的GCD会话详细介绍了调度I/O,并且通过直读()系统调用实现了吞吐量改进的示例比较,用于读取各种大小的许多文件.