BFQスケジューラを有効にして使用するにはどうすればよいですか?

ukuu(Ubuntu Kernel Update Utility https://doc.ubuntu-fr.org/ubuntu_kernel_upgrade_utility )。

利用可能なI / Oスケジューラーを確認すると、BFQもKyber I /も見つからないようです。 Oスケジューラー:

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

では、このLinuxバージョンで新しいスケジューラーの1つを使用するにはどうすればよいですか?

回答

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

BFQはblk-mq(マルチキューブロックIOキューイング)です。メカニズム)スケジューラー。ブート時にblk-mqを有効にする必要があるため、/ etc / default / grubファイルを編集して、scsi_mod.use_blk_mq=1GRUB_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 

bfq

ファイルを追加することで、起動時に追加できます。

blk_mqを有効にすると、blk_mq以外のスケジューラーを使用できなくなるため、noopcfqとnonを失うことに注意してください。 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" 

指摘されたとおりここ必要に応じて、ローテーションを区別できますl属性ATTR{queue/rotational}を使用するudevルール内の(HDD)および非回転(SSD)デバイス。 BFQ開発者のPaoloValenteは、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 iv id = “を搭載したコンピューターではこれを行わないでください' 097127ad57 “>

4.15サスペンドトゥラム; < 4.15は、安全なSCSI静止"の修正。

  • また、カーネル4.14で、blk-mqを有効にするとカーネルに問題が発生する可能性があります" oops "最初から一部のシステムでカーネルをロードするg('は完全停止パニックではなく、カーネル内のnull逆参照のみです)。 '探していない場合は見逃すかもしれませんが、'パラノイアの場合は、何かが壊れている兆候である可能性があります。
  • ' dは、もう少し正確なudevルールを使用することをお勧めします。ここに示すものを試したところ、udevは、名前がそのパターンに一致する一部のデバイスにスケジューラーを設定しようとしましたが、BFQスケジューラーを使用できる' tSCSIブロックデバイスではありません。最終的に得られたルールは次のとおりです。ACTION=="add|change", SUBSYSTEM=="block", DRIVERS=="sd|sr", ATTR{queue/scheduler}!="bfq", ATTR{queue/scheduler}="bfq"デバイス名に対するパターンマッチングを回避し、マッチングをより正確にします。 'には" queue /がないため、'パーティションデバイスと一致しません。スケジューラ"属性。
  • また、カーネル4.15-4.16には、BFQの使用中にドライブのパーティションスキームを更新すると、かなり深刻なバグが発生することに注意してください。完全なI / Oロックアップにつながります。参照: lkml.org/lkml/2017/12/1/80
  • echo bfq > /sys/block/sda/queue/schedulerをrootとして。 (Ubuntu 18.04ではsudoは機能しませんでした)これにより、すぐに有効になります。
  • 回答

    To RomuloPBenedettiの回答を拡張する:

    のudevルール。これは事実上DRIVERS=="sd|sr"に置き換わり、scsi_mod.use_blk_mq=1

    雑学クイズを忘れても発火しません:

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

    コメントを残す

    メールアドレスが公開されることはありません。 * が付いている欄は必須項目です