ブロックデバイスの正確なタイプに依存する場合、各タイプのデバイスのデフォルトのI/Oスケジューラは何ですか?
Fedora 29には、4.19シリーズのLinuxカーネルが含まれています。 (技術的には、最初のリリースでは4.18シリーズのカーネルが使用されていましたが、4.19カーネルは通常のソフトウェアアップデートによってインストールされます)。
バージョン4.19以降、メインラインカーネルにはCONFIG_SCSI_MQ_DEFAULT
がdefault y
として含まれています。つまりこれは、Fedora固有のパッチを適用せずに、Linusによって公開されたツリーを取得した場合に得られるものです。デフォルトでは、SCSIおよびSATAデバイスは新しいマルチキューブロックレイヤーを使用します。 (Linuxは、 SAT標準 に基づく変換を使用して、SATAデバイスをSCSIとして扱います)。
これは、古いコードを削除するための移行手順です。古いコードはすべて削除されます バージョンでは 4.21 5. 、4.20以降の次のカーネルリリース。
新しいMQシステムでは、ブロックデバイスは新しいI/Oスケジューラのセットを使用します。これらには、none
、mq-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スケジューラは何ですか?
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カーネルリストは、これを変更する必要があるかどうかを議論するのに最適な場所です。
あなたの選択に役立つかもしれないいくつかの情報
私はBFQの作者の一人なので、私はほとんど無関心なパーティーです:)しかし、繰り返し可能なテストで得られた数値のみを報告します。
SDカード、eMMC、HDD、SATA SSD、NVMeSSDでBFQをテストしてきました。 HDDとSSDについては、シングルディスク構成とRAID構成の両方でテストを実行しました。
スループットの観点から、結果は次のように要約できます。 SDカード、eMMC、およびHDD(シングルおよびRAID)を使用すると、スループットの点で回帰はありません。対照的に、HDDの場合、ワークロードによっては約20〜30%の増加が見られます。
SSDでは、スループットのみが失われます
上記のオーバーヘッドのため、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