Wie schnell sind Linux-Pipes?
Zusammenfassung
Francesco Mazzoli untersucht in „How fast are Linux pipes anyway?“, wie Pipes im Linux-Kernel arbeiten, indem ein Testprogramm schrittweise optimiert wird. Von anfangs rund 3,5 GiB/s steigt der Durchsatz durch vmsplice, splice, Huge Pages und Busy Looping auf etwa 65 GiB/s. Jeder Schritt wird mit dem Profiler perf und einem Blick in den Kernel-Quellcode begründet.
Worum es geht
Eine Pipe verbindet zwei Programme: Was das eine schreibt, liest das andere. Anlass des Artikels war ein extrem optimiertes FizzBuzz-Programm, das Text mit rund 36 GiB/s in eine Pipe schreibt. Ein naives Programm mit write und read schaffte dagegen nur 3,5 GiB/s, obwohl es gar nichts berechnet.
Der Grund: Bei write und read kopiert der Kernel jeden Block zweimal, einmal aus dem Speicher des schreibenden Programms in einen Ringpuffer der Pipe und einmal wieder heraus. perf zeigte, dass ein Großteil der Zeit genau mit Kopieren und dem Anlegen von Speicherseiten vergeht.
Die Optimierungsschritte
vmsplice und splice übergeben statt der Daten nur Verweise auf Speicherseiten an die Pipe und sparen so Kopien. Danach wird die Verwaltung der Seiten zum Engpass; Huge Pages mit 2 MiB statt 4 KiB reduzieren diesen Aufwand drastisch. Zuletzt ersetzt aktives Warten, das Busy Looping, das Schlafen und Wecken der Prozesse, was Latenz spart, aber dauerhaft einen CPU-Kern belegt. Beide Prozesse wurden zudem mit taskset auf feste Kerne gelegt.
Am Ende stehen rund 65 GiB/s, also etwa das Zwanzigfache des Ausgangswerts. Gemessen wurde auf einem Intel Core i7-8550U mit Linux 5.17.
Was man daraus lernt
Der Artikel ist weniger eine Anleitung für Pipes als ein Lehrstück für Leistungsanalyse: erst messen, dann den Engpass verstehen, dann gezielt ändern. Er erklärt dabei Zero-Copy, Ringpuffer, Seitentabellen und Synchronisationskosten. Splice gilt dabei als heikles Konzept; im März 2022 wurde mit Dirty Pipe eine schwere Lücke im Zusammenspiel von Pipes und splice bekannt.
Ideen
- perf zeigt, wo ein Programm tatsächlich Zeit im Kernel verbringt.
- splice und vmsplice übergeben Seitenverweise statt Daten zu kopieren.
- Huge Pages verringern den Verwaltungsaufwand für viele Speicherseiten.
- Busy Looping tauscht CPU-Zeit gegen geringere Latenz.
Einsichten
- Zero-Copy bedeutet meist weniger Kopien, nicht gar keine.
- Ein schnellerer Mikrobenchmark kann für reale Anwendungen den falschen Ressourcentausch wählen.
Fakten
- Der Durchsatz stieg von rund 3,5 GiB/s auf etwa 65 GiB/s.
- Die Messungen liefen auf einem Intel Core i7-8550U mit Linux 5.17.
- Der Artikel erreichte im Juni 2022 auf Hacker News 698 Punkte und 200 Kommentare.
Referenzen
Bemerkungen
- Der Artikel landete 2023 und 2025 erneut auf Hacker News, jeweils mit dem Zusatz „(2022)“.
Empfehlungen
- Profile zuerst mit perf, bevor du Puffer oder Systemaufrufe austauschst.
- Bewerte Durchsatz, CPU-Verbrauch und Latenz gemeinsam, nicht nur den Spitzenwert.
Links zur Originalquelle und zum Webarchiv öffnen einen neuen Tab.