it-swarm.com.de

Wie aktiviere und verwende ich den BFQ-Scheduler?

Ich habe gerade den Linux-Kernel Version 4.12 unter Ubuntu 17.04 mit ukuu installiert (Ubuntu Kernel Update Utility https://doc.ubuntu-fr.org/ubuntu_kernel_upgrade_utility ).

Die Sache ist, wenn ich die verfügbaren E/A-Planer überprüfe, kann ich weder den BFQ noch den Kyber-E/A-Planer finden:

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

Wie verwende ich einen der neuen Scheduler in dieser Linux-Version?

18
Sidahmed

Ich bin nicht in Ubuntu, aber was ich in Fedora getan habe, kann Ihnen helfen.

BFQ ist ein blk-mq-Scheduler (Multi-Queue Block IO Queuing Mechanism)). Sie müssen also blk-mq beim Booten aktivieren, Ihre Datei/etc/default/grub bearbeiten und scsi_mod.use_blk_mq=1 hinzufügen Für Ihren GRUB_CMDLINE_LINUX ist dies meine Grub-Datei als Beispiel:

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"

Danach müssen Sie Ihren Grub aktualisieren. Auf Fedora müssen wir Sudo grub2-mkconfig -o /path/to/grub.cfg verwenden, was abhängig von der Boot-Methode variiert. Unter Ubuntu können Sie einfach Folgendes ausführen:

Sudo update-grub

Starten Sie neu und wenn Sie dies erhalten:

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

Wahrscheinlich wurde Ihr Kernel mit BFQ als Modul kompiliert , und dies kann auch für Kyber der Fall sein.

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

Sie können es beim Booten hinzufügen, indem Sie eine /etc/modules-load.d/bfq.conf-Datei hinzufügen, die bfq enthält.

Es ist wichtig zu beachten, dass es beim Aktivieren von blk_mq unmöglich ist, Nicht-blk_mq-Scheduler zu verwenden, sodass Sie noop cfq und die Nicht-mq-Frist verlieren .

Anscheinend unterstützt das Planungssystem blk_mq keine Aufzugsflaggen in grub. Stattdessen können udev-Regeln verwendet werden, mit dem Bonus, eine differenziertere Steuerung anzubieten.

Erstellen Sie /etc/udev/rules.d/60-scheduler.rules, falls nicht vorhanden, und fügen Sie Folgendes hinzu:

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

Wie bereits erwähnt hier Bei Bedarf können Sie in udev-Regeln mithilfe des Attributs ATTR{queue/rotational} zwischen rotierenden (HDDs) und nicht rotierenden (SSDs) Geräten unterscheiden. Beachten Sie, dass Paolo Valente, BFQ-Entwickler, in LinuxCon Europe darauf hingewiesen hat, dass BFQ in Bezug auf Garantien mit geringer Latenz eine bessere Wahl sein kann als die Scheduler noop oder deadline, was einen guten Ratschlag darstellt es auch für SSDs.

Paolos Vergleich: https: //www.youtube.com/watch? V = 1cjZeaCXIyM & feature = youtu.be

Speichern Sie es und laden Sie udev rules neu und lösen Sie es aus:

Sudo udevadm control --reload
Sudo udevadm trigger
24

Um großartig zu erweitern RomuloPBenedetti Antwort :

Sie können testen, ob der bfq-Scheduler tatsächlich auf einem bestimmten Gerät verfügbar ist, indem Sie PROGRAM=="/bin/grep -E -q '(^|[[:space:]])bfq($|[[:space:]])' '$sys$devpath/queue/scheduler'" in der udev-Regel verwenden. Dies ersetzt effektiv DRIVERS=="sd|sr" und nur nicht feuern, wenn man scsi_mod.use_blk_mq=1

Wissenswertes:

  • PROGRAM - Führen Sie ein Programm aus, um festzustellen, ob eine Übereinstimmung vorliegt. Der Schlüssel ist wahr, wenn das Programm erfolgreich zurückgegeben wird. Wenn kein absoluter Pfad angegeben ist, wird erwartet, dass das Programm in/lib/udev lebt.
  • $sys - Der sysfs-Mountpunkt (/sys).
  • $devpath - Der Devpath des Geräts (/ device/pci/...).
1
Arano-kai