Software::Kernel
Linux 4.19 soll Netzwerkdurchsatz steigern
Eine naheliegende und bisher übersehene Optimierung wird in der kommenden Version des Linux-Kernels den Netzwerkdurchsatz erhöhen. Allerdings müssen die Treiber dafür angepasst werden. Ob schon in Linux 4.19 alle Treiber angepasst sein werden, ist noch offen.
Larry Ewing
Nachdem
Linux 4.18 vor knapp zwei Wochen freigegeben wurde, wird am Sonntag voraussichtlich der erste Veröffentlichungskandidat von Linux 4.19 erscheinen. Dieser wird eine
interessante Verbesserung enthalten - zumindest für IPv4, später wohl auch für IPv6. Durch diese Verbesserung wird die Verarbeitung von ankommenden Netzwerkpaketen beschleunigt. Der Entwickler geht von einer Beschleunigung von 4% im ungünstigsten Fall aus - in vielen Fällen sind umd die 25% möglich, in einzelnen Fällen sogar 35%. Für die Netzwerkentwickler, die seit Jahren mit rauchenden Köpfen um die Eliminierung jeder einzelnen überflüssigen Instruktion kämpfen, ist das eine enorme Verbesserung, die mit relativ wenig Aufwand erzielt wird.
Es ist lange bekannt, dass grundlegende Geschwindigkeitssteigerungen nur dadurch zu erreichen sind, dass möglichst viele Arbeit mit einem einzelnen Funktionsaufruf erledigt wird. In vielen Subsystemen von Linux wurde das umgesetzt, beispielsweise bei Blockgeräten, wo, wenn es irgendwie möglich ist, nicht einzelne Sektoren oder Blöcke, sondern ganze Bündel von Blöcken auf einmal gelesen oder geschrieben werden. Auch im Netzwerk-Subsystem findet eine solche Bündelung statt. Vor gut 15 Jahren wurde der Empfang von Paketen von Interrupts auf eine neue Methode umgestellt, NAPI-schnittstelle genannt. Wurde zuvor bei jedem ankommenden Paket ein Interrupt ausgelöst, waren Interrupts seither deutlich reduziert. Denn nach jedem empfangenen Paket wurde noch ein wenig gewartet, um eventuell weitere eintreffende Pakete gleich mitzunehmen. Damit konnte der Kernel bis heute mit den schnellsten Netzwerkschnittstellen mithalten, was allerdings auch entsprechend schnelle CPUs voraussetzt.
Es stellte sich nun heraus, dass die Bündelung von Paketen oberhalb der Empfangsschnittstelle bereits endet. Hier wird jedes Paket einzeln per Funktionsaufruf an die höheren Schichten übergeben. Jesper Dangaard Brouer erkannte bereits 2016, dass hier Optimierungspotential besteht. Edward Cree war nun derjenige, der sich der Sache annahm. Er schuf im ersten Schritt eine einfache Funktion, um die Pakete als Liste an die nächste Ebene weiterzugeben. Er ergänzte dies um weitere Funktionen, um die Pakete auch in höheren Ebenen gebündelt zu verarbeiten, bis hin zum IP-Empfangs-Handler. Wenn Pakete in den Zwischenebenen auf verschieden Weise verarbeitet werden müssen, werden die Listen entsprechend aufgeteilt. Normalerweise sorgt eine solche Batch-Verarbeitung für erhöhte Latenzzeiten. In diesem Fall ist sie aber neutral, da die Latenz bereits in der NAPI-Schnittstelle entsteht.
Der Geschwindigeitsgewinn durch diese Maßnahmen ist hauptsächlich durch die bessere Ausnutzung des Befehls-Caches der CPU zu erklären. Der gesamte Code zur Verarbeitung von Paketen ist zu groß, um in den Cache zu passen. Wenn die Pakete also nacheinander verarbeitet werden, müssen große Teile des Caches immer wieder neu geladen werden. Wenn die Pakete dagegen auf jeder Ebene als Bündel verarbeitet werden, kann der Cache sehr viel effektiver genutzt werden.
Die zweite Verbesserung, die die Änderung bringt, ist die Reduzierung von indirekten Sprüngen im Code. Indirekte Sprünge sind durch die Maßnahmen gegen die katastrophalen Prozessorfehler Spectre und Meltdown noch teurer als bisher geworden, sie verlangsamen die Ausführung erheblich.
Um die Verbesserung nutzen zu können, müssen die Netzwerktreiber geändert werden, so dass sie aus den empfangenen Paketen eine Liste konstruieren. Diese Änderung ist ziemlich einfach, wurde aber bisher erst für einen einzigen Treiber, den von Solarflare, Crees Arbeitgeber, durchgeführt. Bis zum Erscheinen von Linux 4.19 gegen Ende September dürften noch einige hinzukommen. Wann alle Treiber angepasst sind, bei denen es möglich ist, ist noch nicht bekannt.
){kind=small}
