linux - Ubuntu Linux 中的异步 IO io_submit 延迟

Question

我正在寻找有关如何为我在 Ubuntu Linux 14.04 上运行的应用程序获得高效和高性能异步 IO 的建议。

我的应用程序处理事务并在磁盘/闪存上创建一个文件。随着应用程序通过事务进行，额外的块被创建，这些块必须附加到磁盘/闪存上的文件中。该应用程序还需要在处理新事务时频繁读取该文件的块。每个事务可能需要从这个文件中读取一个不同的块，此外还要创建一个必须附加到这个文件的新块。有一个传入的事务队列，应用程序可以继续处理队列中的事务，以创建足够深的 IO 操作管道，以隐藏磁盘或闪存上的读取访问或写入完成的延迟。对于尚未写入磁盘/闪存的块(由前一个事务放入写入队列)的读取，应用程序将停止，直到相应的写入完成。

我有一个重要的性能目标——应用程序应该产生尽可能低的延迟来发出 IO 操作。我的应用程序需要大约 10 微秒来处理每个事务，并准备好向磁盘/闪存上的文件发出写入或读取。发出异步读取或写入的额外延迟应尽可能小，以便应用程序可以在仅需要写入文件时以每个事务接近 10 微秒的速率完成每个事务的处理。

我们正在试验一种使用 io_submit 发出写入和读取请求的实现。对于满足我们要求的最佳方法的任何建议或反馈，我将不胜感激。 io_submit 是否会给我们提供最佳性能来实现我们的目标？对于每次写入 io_submit 的延迟和每次读取 io_submit 的延迟，我应该期待什么？

使用我们的实验代码(在 2.3 GHz Haswell Macbook Pro、Ubuntu Linux 14.04 上运行)，我们在扩展输出文件时测量了大约 50 微秒的写入 io_submit。这太长了，我们甚至还没有接近我们的性能要求。任何帮助我以最少的延迟启动写入请求的指导将不胜感激。

Answer 1

Linux AIO(有时称为 KAIO 或 libaio)是一种黑魔法，经验丰富的从业者知道其中的陷阱，但出于某种原因，它是 taboo to tell someone about gotchas they don't already know .通过在网上摸索和经验，我想出了几个例子，其中 Linux 的 通过 io_submit() 提交异步 I/O 可能变得(静默)同步，从而将其变成阻塞(即不再快速)调用:

您正在提交缓冲(又名非直接)I/O。在以下情况下，您会受到 Linux 缓存的支配，并且您的提交可以同步:

您正在阅读的内容尚未在“读取缓存”中。

“写缓存”已满，在某些现有写回完成之前，无法接受新的写请求。

您要求对文件系统中的文件进行直接 I/O，但无论出于何种原因，文件系统决定忽略 O_DIRECT “提示”(例如，您提交 I/O 的方式不符合 O_DIRECT 对齐约束，文件系统或特定文件系统的配置不​​支持 O_DIRECT )并且它选择 silently perform buffered I/O instead ，导致上述情况。

您正在对文件系统中的文件进行直接 I/O，但文件系统必须执行同步操作(例如通过回写读取元数据/更新元数据)才能完成您的 I/O。一个常见的例子是发出“分配写入”(例如，因为您正在附加/扩展文件的末尾或填充未分配的孔)，这听起来像提问者正在做的事情(“附加到文件”) .一些 filesystems such as XFS try harder to provide good AIO behaviour但即使在那里，用户也必须小心避免将某些操作并行发送到文件系统，否则 io_submit()当另一个操作完成时，再次将变成阻塞调用。 Seastar framework contains a small lookup table of filesystem specific cases .

您提交了太多未完成的 I/O。您的磁盘/磁盘 Controller 将具有可同时处理的最大 I/O 请求数，并且每个特定设备都有最大请求队列大小(请参阅 /sys/block/[disk]/queue/nr_requests documentation 和未记录的 /sys/block/[disk]/device/queue_depth ) 在内核中。制作 I/O requests back-up and exceed the size of the kernel queues leads to blocking .

如果您提交“太大”的 I/O(例如，大于 /sys/block/[disk]/queue/max_sectors_kb 但大于 true limit may be something smaller like 512 KiB)，它们将在块层内拆分并继续处理多个请求。

系统全局并发 AIO 请求的最大数量(请参阅 /proc/sys/fs/aio-max-nr documentation)也会产生影响，但结果将在 io_setup() 中看到。而不是 io_submit() .

Linux 块设备堆栈中的请求和提交到磁盘之间的层必须阻塞。例如，Linux 软件 RAID (md) 之类的东西可以使通过它的 I/O 请求停止，同时更新单个磁盘上的 RAID 1 元数据。

您的提交导致内核等待，因为:

它需要使用正在使用的特定锁(例如 i_rwsem )。

它需要分配一些额外的内存或页面。

您将 I/O 提交给不是“常规”文件或块设备的文件描述符(例如，您的描述符是管道或套接字)。

上面的列表是不是 详尽无遗。
>= 4.14 内核时 RWF_NONBLOCK flag可以用来制作上面嘈杂的一些阻塞场景。例如，当使用缓冲并尝试读取尚未在页面缓存中的数据时， RWF_NONBLOCK flag will cause submission to fail with EAGAIN when blocking would otherwise occur .显然，您仍然 a) 需要支持此标志的 4.14(或更高版本)内核，并且 b) 必须了解它未涵盖的情况。我注意到有 patches that have been accepted or are being proposed to return EAGAIN in more scenarios that would otherwise block但在撰写本文时 (2019) RWF_NONBLOCK is not supported for buffered filesystem writes .
备择方案
如果您的内核 >=5.1，您可以尝试使用 io_uring 这在不阻止提交方面做得更好(这是一个完全不同的界面，并且是 2020 年的新界面)。
引用

AIOUserGuide has a "Performance considerations" section警告一些 io_submit()阻塞/缓慢的情况。

不错list of Linux AIO pitfalls在 ggaoed AoE 目标的自述文件的“性能问题”部分中给出。

“在 io_submit 期间休眠并等待”XFS 邮件列表线程提示某些 AIO queue constraints .

“io_submit() 阻止写入大量时间”XFS 邮件列表线程有来自 Dave Chiner 的警告 when an XFS filesystem becomes more than 85-90% full, the chances of unpredictable filesystem delays increases离得越近 ENOSPC由于缺乏大量连续的可用空间。

“[PATCH 1/1 linux-next] ext4:向补丁添加兼容性标志检查”LKML 线程有来自 Ext4 首席开发人员 Ted Ts'o 的回复，谈论如何 filesystems can fallback to buffered I/O for O_DIRECT rather than failing the open() call .

在“ubifs:允许 O_DIRECT”LKML 线程 Btrfs 首席开发人员 Chris Mason 中声明 Btrfs resorts to buffered I/O when O_DIRECT is requested on compressed files .

ZFS on Linux 0.8.0 changed ZoL's behaviour from erroring on O_DIRECT to "accepting" it by falling back to buffered I/O (请参阅提交消息中的第 3 点)。在 ZFS on Linux "Direct IO" GitHub issue 中还有从引导到提交的进一步讨论。 .在“NVMe Read Performance Issues with ZFS (submit_bio to io_schedule)”问题中，有人建议他们是 getting closer to submitting a change that enables a proper zerocopy O_DIRECT .如果接受这样的更改，它最终会出现在 ZoL 的某个 future 版本中大于 0.8.2。

Ext4 wiki 有一个 warning that certain Linux implementations ^(Which?) fall back to buffered I/O when doing O_DIRECT allocating writes .

标题为“内核异步 I/O (AIO) 支持”的 2004 年 Linux 可扩展性工作页面有一个 list of things that worked and things that did not work with Linux AIO (有点旧但快速引用)。

在“io_submit() 需要很长时间才能返回？” linux-aio 邮件列表线程 Zach Brown 解释说 for a file in a filesystem to find out which blocks to issue async I/O against it has to do a synchronous read of metadata (但这些数据通常已经缓存)。

求职信"[PATCH 0/10 v13] merge request: No wait AIO"在 LKML 上列出了 io_submit() 的原因延误。还有一个 LWN article talking about an earlier version of the no-wait AIO patch set以及它没有涵盖的一些情况(但请注意，缓冲读取 最后被它涵盖了 )。

"io_submit blocking" search on the linux-aio mailing list

有关的:

Linux AIO: Poor Scaling

io_submit() blocks until a previous operation will be completed

buffered asynchronous file I/O on linux (但要坚持明确谈论 Linux 内核 AIO)

希望这篇文章对某人有所帮助(如果对您有帮助，您可以点赞吗？谢谢!)。