Warum setzt Ubuntu 16.04 alle Drive-IO-Scheduler auf „Deadline“?

Ich habe gerade Xubuntu 16.04-64bit auf einer zweiten Partition meines Laptops installiert. Ich bemerkte, dass es manchmal etwas langsam zu sein schien, also überprüfte ich, welcher IO-Scheduler für dieses Laufwerk verwendet wurde, was sich deadlinefür alle Laufwerke herausstellte . Ich habe ein paar SSDs und Festplatten, daher weiß ich, dass "Deadline" für SSDs und cfqFestplatten am besten ist .

Ich habe 14.04 auf einer anderen Partition gebootet und es wird cfqfür die rotierenden Laufwerke und deadlinefür die SSD verwendet, wie es sollte. Ich habe auch untersucht, /etc/udev/rules.dob 14.04 eine Regel verwendet, um den Laufwerkstyp zu konfigurieren, diese aber nicht vorhanden war. Ich gehe also davon aus, dass der Kernel dies tut.

Ich frage mich also, ob dies ein Fehler ist oder ob sie jetzt "deadline" für alles verwenden?

Update: Der Kommentar, den ich über /etc/udev/rules.d geschrieben habe, war ein Fehler. Tatsächlich habe ich eine udev-Regel verwendet, um den Scheduler (wie die Antwort unten zeigt) nach Rotationstyp zu ändern, seit ich vor ein paar Jahren mit der Verwendung einer SSD begonnen habe. Ich glaube, ich habe nur vergessen ... alt zu werden. Wie auch immer, eine der Referenzen, die ich verwendet habe, war das Debian-SSD-Optimierungs-Wiki .

Wäre es nicht eine gute Idee, wenn es enthalten wäre? Nur ein Vorschlag!

kernel scheduler

— curt54
quelle

Antworten:

Mit der Veröffentlichung von 14.04 wurde der Standard-Scheduler für den 3.13-Kernel von CFQ auf Deadline geändert .

Es gibt keinen separaten Server-Kernel mehr und der CFQ-Sheduler eignet sich nicht für viele Servernutzungsszenarien, z . B. KVM-Zeitüberschreitungen beim Schreiben . Bei USB-Geräten gibt es sogar Leistungseinbußen auf dem Desktop .

— NGRhodes
quelle

Vielen Dank für das Lesen, sehr aufschlussreich! Das USB-Problem hatte ich schon oft mit SD-Karten und mit evtl. Android-Tablets in TWRP. Bei letzterem würde es gleich am Ende für einige Minuten hängen bleiben. Das KVM-Problem wird auf meinen VB-Gästen nie angezeigt, da sie sich auf meiner SSD mit Deadline befinden.

— Curt54

Das Ubuntu-Kernel-Team führt regelmäßig zahlreiche Analysen verschiedener simulierter Workloads auf verschiedenen Dateisystemen und E / A-Schedulern durch, um sich einen Überblick über die beste Auswahl an generischen E / A-Schedulern zu verschaffen. Die allgemeine Antwort lautet, dass es für eine generische Konfiguration keine perfekte Auswahl an E / A-Schedulern für die verschiedenen Arten von Installationen für die verschiedenen Arten von Medien gibt. Die wichtigsten Punkte, an die Sie sich erinnern sollten, sind:

Die Systeme werden auf SSD umgestellt, daher sind Noop oder Deadline für diese Systeme am besten geeignet. Noop hat weniger CPU-Overhead als Deadline.
CFQ vs Deadline ist ein harter Anruf. CFQ ermöglicht eine größere Flexibilität. Wir haben jedoch festgestellt, dass für einen größeren Bereich simulierter E / A-Vorgänge die Deadline geringere Latenzen und einen etwas höheren Durchsatz als CFQ bietet.
Ich vergleiche regelmäßig die Kernel (jeder Kerneltest dauert mindestens 3 Tage) mit einer Reihe von Dateisystemen und E / A-Schedulern. Aus diesen und anderen sortierten Daten versuchen wir, eine fundierte Entscheidung über die beste Wahl zu treffen, siehe:

http://kernel.ubuntu.com/~cking/fs-tests/

Alle I / O-Scheduler haben Vor- und Nachteile. Daher ist jeder Standard nicht perfekt, und das Ubuntu-Kernel-Team ist immer bereit, Eingaben in die Standardauswahl zu machen, wenn zwingende Daten und Gründe uns aufzeigen, etwas anderes zu ändern.

— Colin Ian King
quelle

Wir haben CFQ als Standard für den Ubuntu Zesty 4.10-Kernel verwendet und auch das neue CONFIG_BLK_WBT_MQ (Multiqueue Writeback Throttling) aktiviert, da dies die Probleme mit dem Writeback des Dirty Cache bei langsamen Geräten wie Flash-Geräten behebt.

— Colin Ian King

Werden wir BFQ jetzt, da es in Kernel 4.12 ist, vielleicht als Standard sehen?

— JauntyDoe

Wir werden dies für 4.12 / 4.13 auswerten, ich habe auch einige frühe Tests mit kyber durchgeführt, aber ich werde diese wieder besuchen, sobald 4.12 diese Woche heraus ist.

— Colin Ian King

Im Prinzip geht es bei dieser Frage nur um den 16.04-Kernel, aber es kommt immer noch auf die Suche :-). Hier ist also ein neueres Update: Ubuntu hat in Ubuntu 17.04 (zesty) bis 18.10 (cosmic) wieder auf CFQ umgestellt, was dem Upstream-Standard entspricht .

— Sourcejedi

Weiteres Update: Linux hat WBT bei Verwendung von CFQ oder BFQ deaktiviert (zumindest standardmäßig), da es nicht gut zusammenarbeitet. 2) Wenn Sie das von WBT gelöste Problem bewerten möchten, müssen Sie sich meines Erachtens darüber im Klaren sein, dass das Problem von Gerät zu Gerät unterschiedlich ist (verschiedene Firmwares). In Ihren Benchmark-Ergebnissen kann ich nicht einmal feststellen, welcher Gerätetyp verwendet wurde. 3) Ich bin gespannt auf Ihre Beschreibung dessen, was WBT löst. Wenn Sie sich das Begleitschreiben zu Version 2 des WBT-Patch-Sets ansehen, ist WBT so konzipiert, dass gepufferte Schreibvorgänge auf schnellem Flash verarbeitet werden können, was zu sehr langen Warteschlangen führen kann und verhindert, dass Leser auf demselben Gerät aushungern.

— Sourcejedi

Ich weiß nicht, warum sich die Entwickler für den deadlineStandard-Scheduler entschieden haben. Vielleicht liegt es daran, dass die meisten neuen Computer mit einer SSD geliefert werden, auf der normalerweise die Systeme installiert sind. Sie können den Scheduler manuell auf diese Weise festgelegt, falls Sie haben es noch nicht installiert ... installieren gksu:

Öffne ein Terminal und führe aus:

sudo apt install gksu

Führen Sie dann diesen Befehl aus:

gksudo gedit /etc/udev/rules.d/60-schedulers.rules

Fügen Sie den folgenden Text in die leere Datei ein und speichern Sie die geänderte Datei.

# set cfq scheduler for rotating disks
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1", ATTR{queue/scheduler}="cfq"

# set deadline scheduler for non-rotating disks
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="deadline"

Starten Sie das Betriebssystem neu und verwenden Sie jetzt die optimalen Scheduler für Festplatten und SSDs.

— cl-netbox
quelle

Ja, genau das hatte ich gemäß meinem Update in der Frage verwendet. Aber ich denke, da es heutzutage üblich ist, beide Arten von Laufwerken zu haben, würde diese Regel in allen Linux-Distributionen enthalten sein.

— Curt54