LWN：测量和改进buffered I/O！

关注了就能看到更多这么棒的文章哦～

Measuring and improving buffered I/O

By Jake Edge
June 5, 2024
LSFMM+BPF
Gemini-1.5-flash translation
https://lwn.net/Articles/976856/

Linux 上存在两种类型的文件 I/O：缓冲 I/O (buffered I/O) 和直接 I/O (direct I/O)。缓冲 I/O 通过页面缓存 (page cache) 进行，而直接 I/O 直接访问存储设备。在 Luis Chamberlain 的 2024 年 Linux 存储、文件系统、内存管理和 BPF 峰会（Linux Storage, Filesystem, Memory Management, and BPF Summit）的主题提案 (topic proposal) 中，指出缓冲 I/O 的性能比直接 I/O 糟糕得多，尤其是在一项特定的测试中。该提案引发了一场邮件列表讨论，并在第二天 Paul McKenney 关于 RCU 的会议 (RCU session) 中被提及；Chamberlain 主持了一个联合存储和文件系统会议来讨论这些结果，并着眼于提高缓冲 I/O 性能。

测试目标

他首先概述了测试的目标，即测量页面缓存的极限并找到提高页面缓存性能的方法。为了提高性能，需要对其进行衡量；具体来说就是需要一种方法来避免在工作过程中引入性能回归 (performance regressions)。他做了很多关于页面缓存的测试，但需要尝试区分正常和病态的使用案例 (use cases)。

基于他所做的测试，以及 Chris Mason 对“正常”测试用例的建议，他想知道是否可以尝试在六个硬盘的 RAID 0 配置中实现缓冲 I/O 和直接 I/O 吞吐量一致 (throughput parity)。Dave Chinner 说“绝对不行”；他认为在那种配置下不可能让两种 I/O 类型达到吞吐量一致性。Chamberlain 建议峰会将是一个很好的场所，可以找出正确的方法、测试和配置来尝试测量和改进页面缓存性能（从而改进缓冲 I/O 性能）。

他在主题提案中提出的病态测试用例是引起了最多关注的一个。在一个资源丰富的系统上，他报告直接 I/O 的写速度为 86GB/s，而缓冲 I/O 的写速度仅为 7GB/s。这是一个巨大的差距；他想知道这是否是可以接受的，或者是否应该被调查并可能被修复。

Chamberlain 说，邮件列表讨论中还有一些其他的结果。Matthew Wilcox 报告了一个 64 字节随机读取 (random reads) 问题引出了 Linus Torvalds 的补丁 (patch)；Kent Overstreet 进行了一些初步测试，发现它带来了 25% 的性能提升。Torvalds 对推动补丁 (patch) 合入的兴趣不大，但 Chamberlain 说他正在进一步测试它，以确保它不会崩溃。

他描述了一些其他在邮件列表讨论中出现的项目，其中一些已通过补丁解决。但病态测试用例的结果似乎是出乎意料的；对此应该怎么做？

Ted Ts'o 说，这类讨论总是围绕着权衡 (tradeoffs) 展开；你会以牺牲一定程度的安全为代价，来换取微基准测试 (microbenchmark) 的性能提升。也可能存在或不存在实际关心微基准测试中所衡量操作的用户空间应用程序 (user-space applications)。例如，他在现实生活中从来没见过任何一个需要进行 64 字节随机读取的应用程序。

他继续说，需要付出努力来确定这些问题是否会对实际应用程序产生影响，还需要付出更多努力来确保正在考虑的任何更改都不会破坏其他应用程序并使情况变得更糟。关于是否值得花时间来调查任何特定问题，需要回答一个哲学问题。

他将正在讨论的问题看作跟 撕裂写入问题 (torn-write problem) 类似的情况。如果解决这个问题，它将对数据库性能带来明显而显而易见的益处；对于提供 64 字节 I/O 的高性能，这一点是否也成立，对他来说还不清楚。在没有实际使用场景的情况下，“值得吗？” 但 Wilcox 说，64 字节读取问题来自一个真正的（且大型的）使用 Linux 的客户。

Chamberlain 说，Ts'o 的观点是有效的，但他在这个会议中的目标并不是找出需要解决的领域；他希望提出一些从他的测试中产生的问题。

并非出乎意料

Chinner 说，病态测试中的数据并不出乎意料。问题的一部分是缓冲 I/O 每个文件系统只有一个回写线程 (writeback thread)，因此 I/O 无法比该线程更快。回写线程是 CPU 绑定的；“不是页面缓存很慢，而是清理页面缓存很慢”，他说。有一些技巧可以绕过这种限制，但需要研究的是如何把清理页面缓存的工作并行化。这可能是使用多个回写线程、使用直写 (writethrough) 或者其他机制；页面缓存的架构对于清理部分来说很难扩展。直写则意味着写入到页面缓存的同时也立即写入到存储设备。

Chamberlain 想知道房间里的人是否普遍同意 Chinner 的观点。Wilcox 说他并不反对，但如何进行扩展是一个有趣的问题。例如，一个需要在多个地方进行回写的单个大型文件，比处理多个需要回写的小型或中型文件更难扩展。

Chinner 说，回写中的大部分 CPU 时间都花在了扫描页面缓存以寻找需要写入的页面上，这与文件的大小没有太大关系。也有一些文件系统特定的考虑因素，但纯覆盖工作负载 (overwrite workload) 将具有更高的回写速率，因为所需的扫描量更少；此时它会遇到 LRU 锁的争用 (contention)。在这个组合中添加更多线程将毫无帮助，甚至可能使情况更糟。

Chinner 经常运行的一个工作负载模拟了一个带有大量文件的 untar 操作，每个文件都被创建、写入 4KB 并被关闭。XFS 在一个通常可以处理 7-8GB/s 的设备上卡在约 50K 个文件/s（约 200MB/s）左右的速度；这里限制就是因为只有单个回写线程。如果他在关闭文件时执行 flush，模拟直写机制，速率将大幅提高（达到 600K 个文件/s 或 2.4GB/s）。这个工作负载的回写问题可以很容易地并行化，但并非总是如此。关键问题是如何尽可能高效地将数据从页面缓存中取出并发送到磁盘。

Jan Kara 说，添加更多回写线程将很困难，因为在各个层级上都假设只有一个回写线程。他和 Chinner 讨论了如何做到这一点，尽管听起来会有很多工作要做。Ts'o 说，可能的原因是 SSD 速度非常快，因此优化这类事物的需求减少了。在 untar 和构建工作负载上获得 20% 的收益，这已经运行得很快了，并不那么吸引人。

Ts'o 说，可能有一些机会在某些类型的设备上简单地关闭回写，因为直写在这类高性能 SSD 上的性能要好得多。Chamberlain 想知道切换到直写是否有助于解决缓冲 I/O 的原子写入 (atomic-write) 问题；Chinner 说有可能。就这样，会议时间到了，尽管有人谈到在峰会后面的 BoF 会议中继续讨论。

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～