Wie schnell sind Linux-Pipes? (2022)

• Untersuchung der Implementierung von Unix-Pipes unter Linux und von Methoden zur Optimierung von Testprogrammen, die Daten über Pipes schreiben und lesen
• Das ursprüngliche Programm erreichte einen Durchsatz von etwa 3,5 GiB/s, der durch verschiedene Optimierungen um das 20-Fache gesteigert wurde
• Diese Optimierungen wurden durch Profiling des Programms mit dem Linux-Tool perf erzielt
• Der Artikel ist inspiriert von einem optimierten FizzBuzz-Programm, das Ausgaben mit etwa 35 GiB/s in eine Pipe schiebt
• Es wird tiefgehend untersucht, wie Pipes intern funktionieren, warum Schreiben in und Lesen aus ihnen langsam ist und wie die Systemaufrufe vmsplice und splice die Leistung verbessern können
• Es wird erläutert, wie Linux-Paging und der Einsatz von Huge Pages zu schnelleren Versionen des Programms führen können
• Die abschließende Optimierung besteht darin, Polling durch eine Busy Loop zu ersetzen
• Die Tests wurden auf einer Intel-Skylake-i7-8550U-CPU und unter Linux 5.17 durchgeführt
• Der Artikel erklärt im Detail, wie Speicher aus Seiten fester Größe aufgebaut ist und wie die CPU Seitentabellen verwendet, um virtuelle Adressen in physische Adressen zu übersetzen
• Der Artikel kommt zu der Beobachtung, dass der Wechsel auf Huge Pages in dem Programm die Leistung um etwa 50 % verbessert
• Es wird außerdem der Einsatz von Huge Pages auf der CPU und die Verringerung von Translation Lookaside Buffer (TLB)-Misses behandelt, was die Leistung verbessern kann
• Der Kernel-Code geht davon aus, dass struct page auf eine Seite der Standardgröße der aktuellen Architektur verweist. Bei Huge Pages enthält die "head"-struct page Informationen über die tatsächliche physische Seite, während die fortlaufenden "tail"-Seiten nur einen Zeiger auf die Head-Seite enthalten
• Neuere Kernel (seit 5.17) enthalten mit struct folio einen neuen Typ, der Head-Seiten explizit identifiziert. Dadurch muss zur Laufzeit seltener geprüft werden, ob eine struct page eine Head- oder Tail-Seite ist, was die Leistung verbessert
• Der Artikel behandelt das Konzept der Busy Loop zur Vermeidung von Synchronisierungskosten. Dabei wird vmsplice angewiesen, zurückzukehren, wenn nicht in die Pipe geschrieben werden kann, und dann in einer Busy Loop zu laufen, bis es wieder bereit ist. Das kann eine Leistungssteigerung von 25 % bringen, hat aber den Preis, einen CPU-Kern vollständig zu belegen, bis vmsplice wieder bereit ist
• Der Autor fasst die im Artikel behandelten Hauptthemen zusammen: Zero-Copy-Operationen, Ringpuffer, Paging & virtueller Speicher, Synchronisierungs-Overhead
• Der Autor räumt außerdem ein, dass es viele weitere Optionen und Details gibt, die im Artikel nicht behandelt werden, entweder weil sie nicht relevant sind oder weil das Interesse daran fehlte
• Der Artikel wurde von den Lesern gut aufgenommen, weil sie ihn als hilfreich und interessant empfanden

[GN⁺]

Hacker-News-Kommentare

• Ein Artikel über die Geschwindigkeit von Linux-Pipes mit Fokus auf vmsplice, das als eine Art Mini-Shared-Memory-Mechanismus zwischen zwei Prozessen funktioniert
• Die Verwendung von vmsplice erfordert beim Lesen und Schreiben eine sorgfältige Behandlung der Puffer und ist komplex, kann aber effizient sein
• Es wird berichtet, dass die Standardimplementierung von Linux-Pipes 20-mal langsamer ist als die optimale Geschwindigkeit
• Der Artikel kommt gut an, und Leser loben seinen informativen Charakter
• Ein Leser weist darauf hin, dass Linux-Pipes deterministisches Verhalten erzeugen können, und verlinkt für weiterführende Lektüre eine externe Quelle
• Es wird die Frage nach einer Datenverarbeitungsbibliothek aufgeworfen, die Abstraktionen über Pipes, Sockets, Dateien und Speicher bereitstellt, und ob diese die im Artikel besprochenen Optimierungen implementiert
• Der Artikel erwähnt APIs wie splice() und vmsplice(), die in den meisten Programmen schwer zu verwenden sind und laut Bericht kaum genutzt werden
• Die Geschwindigkeit von Linux-Pipes wird mit der Geschwindigkeit eines einzelnen Kerns im System verglichen; der Kernel mappt dieselbe physische Speicherseite vom stdout eines Programms auf den stdin eines anderen, wodurch der Vorgang als zerocopy oder in weniger optimierten Fällen als schnelles onecopy erfolgt
• Der Artikel verknüpft das Konzept von Seitentabellen mit der Performance-Analyse mittels perf und betont deren Bedeutung für den Durchsatz
• Ein Leser teilt Erfahrungen mit der Pipe-Implementierung von Cygwin und erwähnt deren geringere Geschwindigkeit im Vergleich zu Linux
• Die Geschwindigkeit von Linux-Pipes wird als ausreichend angesehen, um Befehle wie cat, sed, awk, cut, grep, uniq und jq wiederholt auszuführen und zu kombinieren