Die Neuerungen von Linux 4.12
Seite 3: Neuer I/O-Scheduler(1): BFQ
Der neue Storage-I/O Scheduler "Budget Fair Queueing" (BFQ) verspricht, die Performance von Datenträgern zu steigern. Dabei hängt allerdings vom Datenträger, den eingesetzten Programmen und den Zugriffsmustern ab, ob der Scheduler letztlich die Geschwindigkeit steigert. Am ehesten dürften sich Vorteile bei klassischen Magnetfestplatten zeigen; bei schnellen SSDs dürfte er hingegen kontra-produktiv sein.
Der vornehmlich auf Desktop-Systeme ausgerichtete BFQ teilt den Prozessen ein I/O-Budget zu und nutzt eine Reihe von Tricks, um das System möglichst reaktionsschnell zu machen. So bevorzugt BFQ beispielsweise Leseoperationen, denn auf deren Ergebnis warten Nutzer oftmals. Auch I/O-Operationen von als Echtzeit markierten Prozessen erhalten eine höhere Priorität. Ferner räumt BFQ den Lese- und Schreiboperationen von Programmen, mit denen der Anwender zu interagieren scheint, eine höhere Priorität ein. Das soll die Reaktionsfreude der darunter laufenden Programme steigern; zugleich geht das aber zu Ungunsten von Hintergrundprozessen, die beispielsweise Code kompilieren, eine Datenbank bereithalten oder den Datenträger indexieren. Ferner sammelt BFQ die einlaufenden Lese- und Schreiboperationen kurzzeitig, um sie dann nach Möglichkeit zu bündeln und in einer optimierten Reihenfolge an die Festplatte zu schicken.
Das ist lediglich eine sehr kurze und grobe Beschreibung von BFQ, das mit zahlreichen Heuristiken arbeitet. In Tuning-Kreisen hat der seit mehreren Jahren unabhängig vom offiziellen Kernel entwickelte Scheduler schon länger einen sehr guten Ruf. Gerade bei Magnetfestplatten soll er spürbare Leistungsgewinne erzielen. Auch bei SSDs soll er in bestimmten Situationen die Geschwindigkeit steigern. Aktuelle SSDs sind aber so schnell, dass BFQ allenfalls in bestimmten Situationen von Vorteil sein dürfte: Der von BFQ betriebene Optimierungsaufwand kostet halt Zeit und Prozessorressourcen, die bei schnellen Datenträgern letztlich die Performance reduzieren.
BFQ standardmäßig oft inaktiv
BFQ ist eine Weiterentwicklung des Storage I/O-Schedulers "Completely Fair Queuing" (CFQ), den viele Distributionen seit Jahren standardmäßig nutzen. Das wird vorerst bei vielen Systemen mit Festplatten auch weiterhin so sein, denn beim jetzt in den Kernel integrierten BFQ-Code handelt es sich um eine überarbeitete Variante des klassischen BFQ. Diese Variante baut auf dem in Linux 3.17 integrierten Multi-Queue Block IO Queueing Mechanism (Blk-Mq) auf. Zum Zugriff auf SATA-Festplatten verwenden Linux-Distributionen aber typischerweise Storage-Treiber wie "Ahci". Diese wiederum nutzen derzeit noch die klassische Block-Layer-Infrastruktur, bei der sich eben CFQ einklinkt und BFQ nicht zur Verfügung steht.
Sie können BFQ aber leicht auf vielen Systemen mit Festplatten einsetzen, indem Sie Ahci anweisen, Blk-Mq zu nutzen. Dazu müssen Sie lediglich den Kernel mit dem Parameter scsi_mod.use_blk_mq=y starten oder beim Erstellen des Kernels die Konfigurations-Option SCSI_MQ_DEFAULT setzen. Das wird vermutlich schon bei einer der nächsten Kernel-Versionen nicht mehr nötig sein, denn aus Entwicklerkreisen konnte der Kernel-Log-Autor erfahren, dass Ahci bald standardmäßig auf Blk-Mq zurückgreifen soll. So oder so: Damit BFQ genutzt wird, muss man ihn auch noch explizit aktivieren. Das ist bei jedem Datenträger einzeln nötig und gelingt über Dateien wie /sys/block/sda/queue/scheduler.
Neuer I/O-Scheduler(2): Kyber
Die Infrastruktur, über die sich BFQ in Blk-Mq einklinkt, wurde erst mit Linux 4.11 geschaffen. Über sie dockt auch ein weiterer Storage-I/O Scheduler an, der mit 4.12 zum Kernel stößt: Der maßgeblich von Facebook-Mitarbeitern entwickelte Kyber, der viel simpler als BFQ arbeitet. Er zielt auf ein ganz anderes Einsatzgebiet: Server mit besonders schnellen Datenträgern, die mit mehreren Warteschlangen arbeiten – beispielsweise per PCIe angebundene NVMe-SSDs. Mit Hilfe der verschiedenen Queues arbeitet Kyber darauf hin, Leseoperationen eher auszuführen als Schreiboperationen. Das kann Wartezeiten reduzieren und Systeme reaktionsfreudiger machen, denn Lesen passiert oftmals, weil ein lokaler oder entfernter Nutzer die Daten abruft und daher auf diese wartet. Schreiben erfolgt hingegen bei vielen Programmen asynchron; daher fällt Anwendern eine kleine Verzögerung nicht so leicht auf. Damit es lediglich eine unmerkliche Verzögerung bleibt, erledigt Kyber die Schreiboperationen nach einer Weile aber trotzdem, selbst wenn noch viele Leseoperationen anstehen. Wie bei BFQ lässt sich das Verhalten von Kyber über Dateien in Sysfs an die individuellen Ansprüche und den jeweiligen Workload anpassen.
Details finden sich im Commit-Kommentar zu Kyber und einer Mail aus dessen Begutachtungsphase. Hintergründe zu BFQ liefern einige Commits (u. a. 1, 2, 3, 4, 5) und die Homepage von BFQ, die auch einige Benchmark-Ergebnisse enthält. Ferner findet sich bei LWN.net ein Artikel zu BFQ und Kyber, der die Ansätze grob umreißt. Die nächsten Monate müssen zeigen, wie sich die beiden in der Praxis schlagen. Wie bei neuem Kernel-Code üblich, dürften beide I/O Scheduler noch ein wenig Feintuning benötigen, bevor sie richtig rund laufen.
