Kopieren, ohne die CPU damit zu belasten? Linux kann's. Fehlen nur noch Applikationen, die das neue Feature nutzen. Die Kern-Technik verschafft Anwendungsprogrammierern das Know-how.

Die Datenmengen bei Multimedia & Co. sind für jedes Betriebssystem eine mächtige Herausforderung. Oft müssen mal eben ein paar GByte von der Festplatte gelesen, in die Grafikkarte transportiert oder über das Netzwerkinterface versandt werden. Typischerweise kopiert das OS die Daten dazu gleich mehrfach hin und her (Abbildung 1), was den ganzen Vorgang selbstverständlich verlangsamt.

Abbildung 1: Beim traditionellen Kopieren wird eine Datei bis zu viermal im Speicher kopiert. Unter günstigen Umständen kommt zweimal direkter Speicherzugriff (DMA) zum Einsatz, aber mindestens zweimal durchlaufen die Daten die CPU.

Zum Beispiel bei einem Server, der eine Filmdatei an einen über TCP/IP angebundenen Client sendet: Zuerst wandern die Daten (also der Film) von der Festplatte in den Speicher des Betriebssystemkerns, den Kernelspace. Dann sind die Daten ein zweites Mal unterwegs, um in den Speicherbereich der Server-Applikation zu wandern, den Userspace.

Zum Glück erfolgen zumindest zwei der Kopieraktionen häufig per DMA, nämlich das Lesen von der Platte und die Übergabe an den Ethernet-Controller. Das lindert das Problem aber nur zum Teil. Mindestens zweimal fasst die CPU die Daten an - das können sich auch moderne (HPC, High Performance Computing) Systeme nicht leisten.

Schon seit Längerem verwenden pfiffige Programmierer daher den Systemcall »sendfile()« [1]. Dieser Systemaufruf kopiert Daten von einem Stream in den nächsten, ohne sie dabei im Userspace zwischenzuparken. Leider ist »sendfile()« nicht universell verwendbar. Es lässt nämlich - vereinfacht gesagt - nur das Kopieren von einer auf der Platte liegenden Datei auf einen Socket (Netzwerk) zu. Datei auf Datei, Socket auf Socket oder Socket auf Datei - für »sendfile()« ist das alles unmöglich.

Turbolader

Seit Kernel 2.6.17 tragen die Entwickler den steten Nachfragen nach optimierten Datenkopierfunktionen mit den neuen Systemcalls »splice()«, »tee()« und »vmsplice()« Rechnung. Sie implementieren so genanntes Zero-Copying, was bedeutet, dass die CPU beim Kopieren von Daten nicht mehr beteiligt ist, eine CPU-Last also durch das Kopieren nicht anfällt (Abbildung 2).

Abbildung 2: Disk-to-Disk-Copy: Der erste Aufruf von »splice()« füllt den Kernel-Buffer, der zweite Aufruf überführt die Daten in die neue Datei.

Der Trick besteht darin, die Daten - meist per DMA - von der Quelle (etwa der Festplatte) in einen Kernel-Buffer zu transportieren. Statt die Daten danach weiter in den Userspace und von dort zurück an eine andere Stelle im Kernel zu kopieren, entnimmt der Kernel (etwa der Netzwerktreiber) die Daten direkt dem Kernel-Buffer. Gesteuert wird dieser Vorgang, bei dem die CPU kein einziges Datenbyte anfasst, durch die User-Applikation (siehe Abbildung 2).

Alles, was »splice()« & Co. also brauchen, ist - neben der Eingangsdatenquelle und der Ausgangsdatensenke - ein Kernel-Buffer. Den stellt eine klassische Unix-Pipe zur Verfügung, weshalb sie auch der Dreh- und Angelpunkt der Kernel-Implementierung ist. Der Systemcall »splice()« verbindet einen Filedeskriptor mit dem Anfang (oder Ende) einer solchen Pipe und füllt respektive entleert den zugehörigen Kernel-Buffer. Insgesamt sind bei einer derartigen Kopieraktion also vier Deskriptoren beteiligt (Abbildung 3).

Pipes und Puffer

Wer beispielsweise mit Hilfe von Zero-Copying eine Datei in eine andere kopieren möchte, verbindet mit »splice()« den File-Deskriptor der Quelldatei mit dem einen Ende der Pipe und füllt den Pipe-Buffer. Ein zweiter Aufruf von »splice()« verbindet das andere Ende der Pipe mit der Ausgabedatei und transferiert dadurch den Inhalt des Pipe-Buffers zurück auf die Festplatte. Diese Sequenz wiederholt sich so lange, bis alle Daten kopiert sind. Abbildung 3 verdeutlicht den Unterschied zur traditionellen Kopierfunktion: An die Stelle des Puffers im Userspace tritt der per Aufruf »pipe()« reservierte Kernel-Buffer. Und statt »read()« und »write()« transferiert der neue Systemcall »splice()« die Daten.

Abbildung 3: Statt des Puffers im Userspace legt der Kernel beim Zero-Copying per »pipe()«-Aufruf einen eigenen Puffer an. Der Syscall »splice()« stößt aus dem Userspace das Lesen von Platte in den Kernel-Buffer und das Schreiben aus dem Kernel-Buffer auf die Platte an.

Um mehreren Programmen parallel Zugriff auf die im Kernel-Buffer befindlichen Daten zu ermöglichen, bietet Linux den Systemcall »tee()« an. In seiner Funktion ähnelt er dem von der Shell bekannten Tee-Kommando. Er erlaubt es, Daten aus dem Pipe-Buffer auszulesen und an eine (andere) Pipe weiterzureichen (siehe Abbildung 4). Damit lassen sich beispielsweise die von einem DVB-T-Gerät empfangenen Daten per »tee« gleichzeitig mit einen Videoplayer anschauen und auf Festplatte speichern. »tee()« kopiert die Daten dabei nicht, sondern arbeitet allein mit Referenzen. Häufig ist die Pipe, an die »tee()« die Daten weiterreicht, die Standardausgabe Stdout (»STDOUT_FILENO«).

Auf der Kommandozeile sieht eine solche Befehls-Pipeline so aus:

splice-in /dev/dvbt | splice-tee film.mpeg | splice-out /dev/tvout

Doch sollten Programmierer aufpassen: Wer von einer Quelle zwei Kopien ziehen möchte - wobei keine der Kopien nach Stdout geht -, braucht auch zwei Pipes! Der Pseudo-Code in Abbildung 5 gibt die Struktur einer solchen Kopierapplikation wieder.

Die Applikation schließlich übergibt die Daten wieder dem Kernel, damit er sie über das Netzwerkinterface an den Client-Rechner schickt. Dazu kopiert der Netzwerktreiber die im Kernel deponierten Daten in den Speicher des Ethernet-Controllers.

Abbildung 4: Der Systemcall »tee()« bindet noch einen zweiten Kernel-Buffer zwischen die Eingabequelle und den duplizierten Ausgabekanal. Doch keine Angst vor unnötigen Datenduplikaten: Der Kernel arbeitet intern nicht mit einer Kopie, sondern nur mit einer Referenz.

Abbildung 5: Der vorgestellte Pseudo-Code legt zwei Kopien einer Datei an.

Der dritte hier vorgestellte Systemcall »vmsplice()« macht die im Userspace bereits vorhandenen Speicherbereiche dem Kernel zugänglich. Ohne Kopieraktion der Daten vom User- in den Kernelspace überträgt der Kernel die ihm anvertrauten Daten zur Peripherie per DMA und umgekehrt. Es handelt sich damit - abgesehen von der mit dem Systemcall verbundenen Kopieraktion - gewissermaßen um ein Gegenstück zu »mmap()« [3], das Speicherbereiche im Kernelspace einer Applikation zugänglich macht. Der zugehörige Filedeskriptor ist wieder einmal eine Pipe. Die genaue Aufrufsyntax der Systemcalls und der zugehörigen Parameter beschreibt der Kasten "Neue Systemcalls im Überblick".

int splice(int fdin, loff_t *off_in, int fdout, loff_t *off_out, size_t len,unsigned int flags)

int tee(int pipe_in, int pipe_out, size_t len, unsigned int flags)

int vmsplice(int fd, const struct iovec *iov, unsigned long nr_segs, unsigned int flags)

Sie können diesen Artikel als PDF für 99 Cent kaufen. Klicken Sie dazu einfach auf eine der beiden Bezahloptionen Paypal oder ClickandBuy.

Kopieren, ohne die CPU damit zu belasten? Linux kann's. Fehlen nur noch Applikationen, die das neue Feature nutzen. Die Kern-Technik verschafft Anwendungsprogrammierern das Know-how.