grand-central-dispatch - dispatch_io 很好地解决了哪些本地存储 I/O 模式？

Question

我是 Grand Central Dispatch 的忠实粉丝，我最近一直在看 dispatch_io_*家庭电话。很容易看出这个 API 如何对网络 I/O 有用(慢，高延迟)。也就是说，dispatch_io_create_with_path 的存在有点暗示在本地文件系统上使用。 (是的，我知道路径也可以指向远程网络文件系统上的资源，但无论如何......)在玩弄它时，我观察到使用 dispatch_io_*与使用简单的阻塞 I/O 调用( read 、 write 等)相比，似乎会带来相当大的开销。这种减速似乎主要来自用作 block 的内核同步原语在队列之间来回编码。在我一直在使用的示例工作负载中(非常受 I/O 限制)，减速可能高达 10 倍。一方面，它看起来像 dispatch_io对于健谈的(小颗粒)I/O 来说永远不会是胜利。

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

如果您的工作负载受 CPU 限制，那么根据定义，您已经可以比处理数据更快地读取/写入数据。

如果您的工作负载受 I/O 限制(在这种情况下 -- 一个本地物理卷)，请使用 dispatch_io无法让您的磁盘更快地为您提供数据。

从那里开始，我认为这个 API 的最佳点可能在中间——一个在 CPU 密集型和 I/O 密集型之间摇摆不定的工作负载，但在这一点上，我有点认为自己陷入了困境，所以我想我会问 StackOverflow。

我将接受第一个描述具有这些先决条件的“真实世界”工作流程(即单台机器，单个本地物理磁盘)的答案，其中使用 dispatch_io将产生显着的性能改进。

Answer 1

从本地文件系统调度 I/O 的主要用例是大文件的异步 IO，或同时读取/写入的许多文件(特别是如果文件的内容可以增量处理)。

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

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

来自 WWDC11 的 GCD session 详细介绍了调度 I/O，并通过示例比较了通过直接 read() 系统调用实现的吞吐量改进，以读取许多不同大小的文件。