web-dev-qa-db-ja.com

Fedora Workstation29はデフォルトのI / Oスケジューラーとして何を使用しますか?

ブロックデバイスの正確なタイプに依存する場合、各タイプのデバイスのデフォルトのI/Oスケジューラは何ですか?

背景情報

Fedora 29には、4.19シリーズのLinuxカーネルが含まれています。 (技術的には、最初のリリースでは4.18シリーズのカーネルが使用されていましたが、4.19カーネルは通常のソフトウェアアップデートによってインストールされます)。

バージョン4.19以降、メインラインカーネルにはCONFIG_SCSI_MQ_DEFAULTdefault yとして含まれています。つまりこれは、Fedora固有のパッチを適用せずに、Linusによって公開されたツリーを取得した場合に得られるものです。デフォルトでは、SCSIおよびSATAデバイスは新しいマルチキューブロックレイヤーを使用します。 (Linuxは、 SAT標準 に基づく変換を使用して、SATAデバイスをSCSIとして扱います)。

これは、古いコードを削除するための移行手順です。古いコードはすべて削除されます バージョンでは 4.21 5. 、4.20以降の次のカーネルリリース。

新しいMQシステムでは、ブロックデバイスは新しいI/Oスケジューラのセットを使用します。これらには、nonemq-deadline、およびbfqが含まれます。メインラインの4.19カーネルでは、デフォルトのスケジューラーは次のように設定されています。

/ * blk-mqデバイスの場合、単一キューデバイスの場合はデフォルトでmq-deadlineを使用します。期限が利用できない場合OR複数のキューがあり、デフォルト「なし」に。* /

mq-deadlineの代わりにBFQをデフォルトとして使用することが提案されています。この提案は4.19では受け入れられませんでした。

従来のSQブロック層の場合、デフォルトのスケジューラーはCFQであり、これはBFQに最も類似しています。

=>カーネルのデフォルトのI/Oスケジューラは、デバイスのタイプ(SCSI/SATA、MMC/eMMCなど)によって異なります。

CFQは、ある程度の「公平性」とI/O優先度(ionice)をサポートしようとします。さまざまな複雑さがあります。 BFQはさらに複雑です。 ioniceをサポートしますが、一部のI/Oを自動的に分類して優先順位を付けるヒューリスティックもあります。 deadlineスタイルのスケジューリングはより簡単です。 ioniceはまったくサポートしていません。

=> Linuxのデフォルトのカーネル構成、SATAデバイス、および追加のユーザースペースポリシーがない(たとえば、udevルールがない)ユーザーは、4.19で動作が変更される可能性があります。 ioniceが機能していた場所では、効果がなくなります。

ただし、Fedoraには特定のカーネルパッチ/構成が含まれています。 Fedoraには、デフォルトのudevルールなどのユーザースペースポリシーも含まれています。

Fedora Workstation29はデフォルトのI/Oスケジューラーとして何を使用しますか?ブロックデバイスの正確なタイプに依存する場合、各タイプのデバイスのデフォルトのI/Oスケジューラは何ですか?

2
sourcejedi

Fedora 29には4.18.16カーネルが付属しています。 CFQがデフォルトのようです。

$ grep CONFIG_DEFAULT_IOSCHED= /boot/config-4.18.16-300.fc29.x86_64 
CONFIG_DEFAULT_IOSCHED="cfq"
$ grep CONFIG_SCSI_MQ_DEFAULT /boot/config-4.18.16-300.fc29.x86_64 
# CONFIG_SCSI_MQ_DEFAULT is not set
$ cat /sys/block/sda/queue/scheduler
noop deadline [cfq] 

この記事の執筆時点(2018年11月24日)では、4.19.3がF29のアップデートとして利用可能です。ただし、構成オプションは変更されていないようです。

4.20.0(RC1)は「Rawhide」開発ツリーにあります。その開発ツリーカーネルでは、CFQはstillがデフォルトであり、CONFIG_SCSI_MQ_DEFAULTはまだ設定されていません。 https://lists.fedoraproject.org/archives/list/[email protected]/ のFedoraカーネルリストは、これを変更する必要があるかどうかを議論するのに最適な場所です。

3
mattdm

あなたの選択に役立つかもしれないいくつかの情報

私はBFQの作者の一人なので、私はほとんど無関心なパーティーです:)しかし、繰り返し可能なテストで得られた数値のみを報告します。

SDカード、eMMC、HDD、SATA SSD、NVMeSSDでBFQをテストしてきました。 HDDとSSDについては、シングルディスク構成とRAID構成の両方でテストを実行しました。

スループットの観点から、結果は次のように要約できます。 SDカード、eMMC、およびHDD(シングルおよびRAID)を使用すると、スループットの点で回帰はありません。対照的に、HDDの場合、ワークロードによっては約20〜30%の増加が見られます。

SSDでは、スループットのみが失われます

  • ランダム同期I/Oの場合:平均的なSSDで約2〜3%、非常に高速なNVMe SSDで最大10〜15%。 BFQを最も困難な状態にすることを目的としたワークロードでは、18%の損失に達しました[1]が、他のサードパーティのテストでは、最悪の場合、損失は約10%です。この損失は主に、BFQが最小のI/Oスケジューラではないという事実によるものです。私たちはこれに取り組んでいます。簡単ではない;このギャップを埋めるには時間が必要です。
  • 非常に高速なSSDでの書き込みI/Oのみ:約5〜10%。これは、I/O要求タグの問題が原因です。私たちはすでに解決策を見つけました。この問題は重大であるとは考えていないため、TODOリストの他の項目を優先しています。そうでなければ、私たちは優先順位を変更する用意があります。

上記のオーバーヘッドのため、BFQはコモディティCPUで400〜500KIOPSを超える処理を行うことはできません。

時間に敏感なアプリケーション(オーディオ/ビデオプレーヤーなど)の応答性と遅延の点では、結果は単純に比類のないものです。たとえば、バックグラウンドでのI/Oワークロードに関係なく、BFQアプリケーションでは、ドライブがアイドル状態であるかのようにすばやく起動します。他のスケジューラーでは、アプリケーションに10倍の時間がかかるか、まったく起動しない場合があります(バックグラウンドワークロードが終了するまで)[1]。

さらに、サーバーのようなワークロードの場合、BFQを使用すると、たとえば、I/O帯域幅の必要な部分を各クライアント(またはコンテナー、VM、またはその他の種類のエンティティ共有ストレージ)に保証し、合計に達することができます。 I/Oを制御するための他のソリューションが到達するスループットとは比較にならないスループット[2]。

最後に、特定のワークロードについて疑問がある場合は、喜んでテストします。

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

[2] https://lwn.net/Articles/763603/

0
Paolo Valente