【翻译】 区块层功能与性能之间的平衡

您知道吗......？ LWN.net 是一份由订阅者支持的出版物；我们依靠订阅者来维持整个运作。 请通过订阅来帮助我们，让 LWN 继续在网络上运行。

早在 9 月份，LWN 就 报道了一系列块层优化工作，这些优化工作使装备适当的系统能够维持每秒 350 万次 I/O 操作 (IOPS)。 自那时起，优化工作一直在继续，而现在这 350 万 IOPS 将是一个令人深感失望的结果。 不过，最近在增加一项新功能上出现的分歧凸显了经过大量优化的区块层的潜在代价；什么时候一项功能的重要性足以超越对最高性能的追求？

块子系统维护者延斯-阿克斯博（Jens Axboe）一直在努力提高块 I/O 操作的速度。 最近的一轮补丁调整了各种快速路径，将插拔机制改为使用单链表，并做出了其他各种小改动。 每项优化都很小，但随着时间的推移，这些工作都在不断增加；现在的性能水平达到了 820 万 IOPS，远远超过了 9 月份的速度，这在当时看起来还不错。 这项工作后来作为 5.16版块拉取请求的一部分进入了主线。

到目前为止，一切都很好；很少有人会对性能的大幅提升提出异议。 但他们可能会反对那些可能会干扰（哪怕是微小干扰）这些改进的变更。

例如，考虑一下 Jane Chu 的这个补丁集。 它在preadv2()和pwritev2()系统调用中添加了一个新标志(RWF_RECOVERY_DATA)，试图从非易失性内存 "中毒 "中恢复的应用程序可以使用该标志。 非易失性内存的实现有不同的方法来检测和处理数据损坏；英特尔内存似乎会对受影响的范围进行 "中毒"，这意味着如果不产生错误（然后变成SIGBUS信号），就无法对其进行访问。 应用程序可以通过读取或写入带有新标记的中毒范围来应对该错误；读取将用 0 替换中毒数据（允许应用程序获取任何仍可读取的数据），而写入将覆盖该数据并尝试清除中毒状态。 无论采用哪种方式，应用程序都可以尝试从问题中恢复并继续运行。

克里斯托夫-赫尔维格（Christoph Hellwig）反对这个新标记，理由是它会降低 I/O 快速通道的速度：

我的观点是，根据定义，从位错误中恢复并不是快速路径。 这就是为什么我宁愿让它远离 pmem 读/写快速路径，而这恰好也是非内存读/写路径（重要得多）。

Pavel Begunkov 也抱怨说，每个标记都会增加一些开销，随着时间的推移，这些开销就会越积越多："默认配置内核在处理真正快速的设备时已经很慢了，而且情况并没有好转"。 这引起了 Darrick Wong 的疑问："所以我们不能进行数据恢复，因为快速运行是唯一的目标？贝根科夫否认了这一说法，但并不清楚他到底在说什么。

在不使用这种标志的情况下，其成本微乎其微，甚至无法衡量。 但对于那些致力于尽可能提高持续 IOPS 的开发人员来说，即使是这样的开销也是无法接受的。 一个标记导致另一个又一个标记，在未来的某一天，性能成本就会变得非常高昂--或者说，无论如何都会出现这种情况。 为了避免出现这种问题，这种观点还在继续，像非易失性内存中毒恢复这样的利基功能应该限制在内核中那些不被视为快速通道的部分。 在这种情况下，有人建议并尝试将所需功能添加到fallocate()，但最终决定fallocate()不适合用于毒药清除等硬件管理功能。

戴夫-钱纳（Dave Chinner）认为目前的优化工作都是错误的：

他认为当前的优化工作是错误的：当前以牺牲其他一切为代价，过度优化 IO 路径以获得最大单核 IOPS 的做法，在过去已被证明是错误的 IO 路径开发方法。是的，我们需要关注性能并努力提高性能，但我们不应该以牺牲 IO 栈需要完成的其他功能为代价。

他接着说，优化应该在所需功能实现之后进行；"使用'快速路径优化'作为阻止新功能实现的钝器实在是......令人讨厌"。

对话很快就中断了。 几十年来，这种关于特性和性能的分歧已经在内核社区中出现过很多次。 更快是一个众所周知的目标，而专注于性能的开发者们已经厌倦了因功能增加而导致的性能退步。 但是，功能也很重要，开发人员厌倦了因看似无关紧要的性能问题而阻碍所需的功能。

通常情况下，与性能相关的反弹会导致修改后的解决方案在性能方面的成本降低；因此，值得注意的是，Hellwig提出了一些改进非易失性内存 I/O 处理方法的想法。 有时，这只会导致所需的功能被延迟或完全阻塞。 目前还不清楚在这种情况下会发生什么，但几乎可以肯定的是，在未来的几十年里，类似的争论还将继续。 归根结底，这就是如何在性能和功能之间找到正确的平衡点（希望如此）。

---

(登录以发表评论)