CONFIG_WBTとBFQについて読みました。私のハードドライブでWBTとCFQを比較してみました。 CFQはLinuxの大規模な非同期書き込みストレージを制御しようとしますが、ハードディスク上の書き込みストレージキャッシュが成功率を制限することを知っています。マイドライブでハードウェア書き込みキャッシュを無効にすると（NCQは有効なまま）、制御機能が大幅に向上しました。 [1]
[1]書き込み保存制限（CONFIG_WBT）の具体的な利点を確認する
これで、CFQ / BFQでWBTが無効になっていることがわかりました。また、アップストリームLinux v4.19ではblk-mqをscsiのデフォルトとして指定するため、Fedoraなどのディストリビューションは評価時にデフォルトでCFQからBFQに切り替えるか、「以前の」ブロック層に戻す必要があります。だからBFQについて知りたいです。
BFQには2つのハードウェア側のヒューリスティックがあることを読んだ。デバイス書き込みキャッシュの影響を軽減するために、書き込みを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に減少しました。したがって、現在の過充電要因は私にとってあまり心配されていません:-).
cgroups I / O制御を研究しながら、bfqで2つの迷惑なバグを発見しました。単一のプロセスグループで簡単な構成で帯域幅制御を中断します。これらのバグは、このシリーズの最初の2つのパッチで修正されました。
この修正により、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によると、純効果は公正なスケジューラで期待できるということです。つまり、実行する入出力タイプに関係なく、プロセスまたはプロセスグループ間で帯域幅を公平に配布することです。この報酬の問題はコメントで説明しますか？そう思うならそうします。
それにもかかわらず、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