BFQスケジューラを有効にして使用する方法

Ubuntu 17.04にukuu（Ubuntu Kernel Update Utility https://doc.ubuntu-fr.org/ubuntu_kernel_upgrade_utility）を使用してLinuxカーネルバージョン4.12をインストールしました。

問題は、使用可能なI / Oスケジューラーを確認したときに、BFQもKyber I / Oスケジューラーも見つからないように見えることです。

cat /sys/class/block/sda/queue/scheduler
> noop deadline [cfq]

それでは、このLinuxバージョンで新しいスケジューラの1つを使用する方法は？

linux-kernel scheduling

— シダメド
ソース

私はUbuntuではありませんが、Fedoraでやったことがあなたを助けるかもしれません。

BFQはblk-mq（マルチキューブロックIOキューイングメカニズム）スケジューラです。したがって、起動時にblk-mqを有効にし、/ etc / default / grubファイルを編集してに追加するscsi_mod.use_blk_mq=1必要がありますGRUB_CMDLINE_LINUX。これは私のgrubファイルです。例：

GRUB_TIMEOUT=3
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=false
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="quiet vt.global_cursor_default=0 scsi_mod.use_blk_mq=1"
GRUB_DISABLE_RECOVERY="true"

その後、grubを更新する必要があります。Fedoraでは使用する必要がありますがsudo grub2-mkconfig -o /path/to/grub.cfg、これはブート方法によって異なります。Ubuntuでは、次を実行できます。

sudo update-grub

再起動し、これを取得した場合：

cat /sys/block/sda/queue/scheduler
[mq-deadline] none

おそらく、あなたのカーネルはモジュールとしてBFQでコンパイルされており、これはKyberにも当てはまります。

sudo modprobe bfq
sudo cat /sys/block/sda/queue/scheduler
[mq-deadline] bfq none

/etc/modules-load.d/bfq.confを含むファイルを追加することで、ブート時に追加できますbfq。

blk_mqを有効にすると非blk_mqスケジューラーを使用できなくなるため、noop cfqと非mq deadlineが失われることに注意することが重要です。

どうやらblk_mqスケジューリングシステムはgrubでエレベーターフラグをサポートしていないようです。代わりに、udevルールを使用して、よりきめ細かな制御を提供することができます。

/etc/udev/rules.d/60-scheduler.rules存在しない場合は作成し、追加します：

ACTION=="add|change", KERNEL=="sd*[!0-9]|sr*", ATTR{queue/scheduler}="bfq"

必要に応じてここで指摘したように、属性を使用してudevルールで回転（HDD）デバイスと非回転（SSD）デバイスを区別できますATTR{queue/rotational}。BFQ開発者のPaolo ValenteはLinuxCon Europeで、BFQが低遅延の保証という点でスケジューラnoopやdeadlineスケジューラよりも優れた選択肢であり、SSDでも使用することをお勧めしていることに注意してください。

Paoloの比較：https : //www.youtube.com/watch?v=1cjZeaCXIyM&feature=youtu.be

保存して、リロードしてトリガーしudev rulesます：

sudo udevadm control --reload
sudo udevadm trigger

— ロムロ・ペネデッティ
ソース

注意したいのは、Linuxで4.15未満のコンピューターでこれを実行しないでください。<4.15は、「安全なSCSI静止」修正がないため、再開時にすべてのIOをハングさせます。

— イヴァンコジック

カーネル4.14で問題が発生する場合もあります。この場合、blk-mqを有効にすると、一部のシステムでカーネルのロードの開始時にカーネルに "oops"が表示されます（完全停止パニックではなく、カーネル内でnullの間接参照が発生します）。あなたがそれを探していないなら、あなたはそれを見逃すかもしれませんが、あなたが妄想しているなら、それは何かが壊れているというサインかもしれません。

— CR。

少し正確なudevルールを使用することをお勧めします。ここに示したものを試したとき、udevは、そのパターンに一致する名前のデバイスのスケジューラーを設定しようとしましたが、BFQスケジューラーを使用できるSCSIブロックデバイスではありません。ルールは次のとおりACTION=="add|change", SUBSYSTEM=="block", DRIVERS=="sd|sr", ATTR{queue/scheduler}!="bfq", ATTR{queue/scheduler}="bfq"です。デバイス名に対するパターンマッチングを回避し、マッチングをより正確にします。「キュー/スケジューラ」属性がないため、パーティションデバイスとは一致しません。

— ダンモールディング

また、カーネル4.15-4.16にはかなり深刻なバグがあり、BFQの使用中にドライブのパーティションスキームを更新すると、I / Oが完全にロックアップする可能性があります。Cf .: lkml.org/lkml/2017/12/1/80

— グルタニメート

素晴らしいRomuloPBenedettiの答えを拡張するには：

PROGRAM=="/bin/grep -E -q '(^|[[:space:]])bfq($|[[:space:]])' '$sys$devpath/queue/scheduler'"udevルールを使用して、特定のデバイスでbfqスケジューラが実際に使用可能かどうかをテストできます。これは効果的に置き換えられDRIVERS=="sd|sr"、忘れた場合は発砲しませんscsi_mod.use_blk_mq=1

トリビア：

PROGRAM-プログラムを実行して、一致するかどうかを判断します。プログラムが正常に戻った場合、キーはtrueです。絶対パスが指定されていない場合、プログラムは/ lib / udevにあると予想されます。
$sys-sysfsマウントポイント（/sys）。
$devpath -デバイスのdevpath（/ devices / pci / ...）。

— あらの会
ソース