☰

bfq_async_charge_factor 表示异步写入的设备吞吐量份额比“公平”份额小 10 倍。我怎样才能观察到这一点？

tag-icon • tag-icon linux-kernel io
bfq_async_charge_factor 表示异步写入的设备吞吐量份额比“公平”份额小 10 倍。我怎样才能观察到这一点？

我一直在阅读有关 CONFIG_WBT 和 BFQ 的文章。我尝试在我的硬盘上比较 WBT 和 CFQ。我了解到 CFQ 试图控制 Linux 的大规模异步写回，但由于硬盘的写回缓存，其成功率有限。在我的驱动器上禁用硬件写缓存（但保持 NCQ 启用）可以大大改善控制。[1]

[1]确定写回限制 (CONFIG_WBT) 的具体好处

我知道 WBT 现在在 CFQ/BFQ 上被禁用。此外，由于上游 Linux v4.19 将 blk-mq 作为 scsi 的默认设置，因此 Fedora 等发行版需要默认从 CFQ 切换到 BFQ，或者切换回“旧”块层，等等，根据它们的情况评价。所以我想了解一下BFQ。

我读到 BFQ 有两个硬件端启发式方法。它将写入“过度充电”10 倍，以减轻设备写入缓存的影响。它还尝试使用空闲来减轻 NCQ 的影响。目前，我最困惑的是写入过量。

为了保持写入请求数与所服务的读取请求数之间的比率较低，我们只是添加了一个写入（超额）费用系数：对于每个写入的扇区，活动应用程序的预算将按此系数而不是 1 减少。正如我们的实验结果所示，等于 10 的系数证明可以有效保证高吞吐量和低延迟。

http://algo.ing.unimo.it/people/paolo/disk_sched/bf1-v1-suite-results.pdf

/*
 * Async to sync throughput distribution is controlled as follows:
 * when an async request is served, the entity is charged the number
 * of sectors of the request, multiplied by the factor below
 */
static const int bfq_async_charge_factor = 10;

https://elixir.bootlin.com/linux/v4.18/source/block/bfq-iosched.c#L190

（当禁用写回缓存时，我在 BFQ 中没有看到任何代码来禁用此因素。我看到 WBT 包含一些代码来跟踪是否启用了写回缓存，出于非常相似的原因。原则上我认为 BFQ 可以做同样的事情，但现在看来 BFQ 会总是过度写入，尽管 BFQ 声称仅在具有写回缓存的设备上需要它）。

这表示异步写入在设备吞吐量中所占的份额将低得多。有没有一个简单的测试用例来观察这种“不公平”的份额？还是我理解有误？

我上面的链接包括 BFQ 的快速测试。这是使用基本默认设置的同时读取和写入fio。我认为 BFQ 给了读者和作者更接近“公平”的份额。 （阅读器在我的硬盘上达到了 40MB/s）。

答案1

v4.19 中的过度充电系数已从 10 降低到 3。所以当前的过度充电系数并没有引起我太多的注意:-)。

[补丁修正/改进 0/4]

在研究 cgroups I/O 控制时，我在 bfq 中发现了两个令人讨厌的错误。它们通过单进程组打破了简单配置中的带宽控制。这些错误已由本系列的前两个补丁修复。

这些修复极大地改进了 I/O 控制，以至于我可以减少 bfq 用来应对写入引起的问题的写入过量系数。这种减少是由第三个补丁执行的。

事实上，通过在我的笔记本电脑硬盘上进行测试，我发现 v4.18 稳定版和 v4.19 稳定版内核之间存在非常明显的差异。我vmstat 1在运行同步读/写测试时使用 观察了读吞吐量与写吞吐量：

fio --ioengine=psync --size=2G --name=read --rw=read --name=write --rw=write

在 4.18 稳定版内核上，编写器首先完成。在 v4.19-stable 上，读者首先完成。但动态更有趣。在 v4.19 上，vmstat 1主要显示读取器被授予写入器吞吐量份额的 2-3 倍，只有一些特殊的示例。在 v4.18 上，读取器和写入器之间的吞吐量波动很大。

这本身并不是结论性的。但我忍不住去思考那些明显的假设。 1) 也许最初的 10 倍超额收费包含了相当大的“捏造因素”，以补偿 BFQ 中实际存在的错误？ 2) 也许在 v4.19 中，超额系数 3 解释了为什么读取器分配的吞吐量份额是写入器吞吐量份额的 2-3 倍？

我还在 BFQ 邮件列表上发布了这个问题，Paolo Valente 试图给我一个答案。他向我指出了 v4.19 中的过度收费变化。他还表示，过度充电因素不仅仅与硬件写入缓存有关：

换句话说，通过保持所服务的异步写入请求与所服务的读取请求之间的较低比率，里面bfq，最终的效果是人们对公平调度程序的期望：进程或进程组之间公平的带宽分配，无论它们执行哪种类型的 I/O。也许我应该在评论中解释一下这个补偿问题，对吧？如果你这么认为，我就这么做。

无论如何，bfq 的这种内部“补偿”的其他实际后果是报告的无与伦比的更好的响应结果，例如，在此处的图 2 和图 5 中（以及在许多其他地方）：

http://algo.ing.unimo.it/people/paolo/disk_sched/results.php

（我特别指的是后台写入的情况）；或者图 1 和图 4 中同一页面的后台写入的吞吐量结果。

随机 I/O 与顺序 I/O 相比，事情会变得更加复杂，但这是一个不同的故事。

https://groups.google.com/forum/#!topic/bfq-iosched/yjZDn_HnLIc

相关内容