Ohne Pinning verteilt der Xen-Hypervisor die virtuellen Prozessorkerne zufällig über die Hardware (rechts) und verschleiert so das Latenz-Muster.

Anil Madhavapeddy, Forscher an der Universität Cambridge, hat sich in seinem Fosdem-Vortrag mit der Optimierung von Interprozesskommunikation (IPC) auf moderner Hardware beschäftigt.

Durch Virtualisierung, Multicore- und NUMA-Architekturen haben Unix-Anwendungen immer mehr Bedarf, miteinander zu kommunizieren, leitete der Brite seinen Vortrag ein. Madhavapeddy hat in seinem Forschungsteam Mechanismen wie Pipes, Unix Domain Sockets, TCP und Shared Memory auf unterschiedlichen Mikroarchitekturen untersucht.

Dabei ergeben sich je nach Verteilung der Prozessorkerne auf Sockets und je nach Speicherarchitektur unterschiedliche Latenzmuster – manche leicht erklärbar, manche rätselhaft. Kommt zudem noch eine Virtualisierungstechnologie wie Xen zum Einsatz, spielen zusätzlich noch deren Implementierungsdetails eine Rolle.

Ohne Pinning verteilt der Xen-Hypervisor die virtuellen Prozessorkerne zufällig über die Hardware (rechts) und verschleiert so das Latenz-Muster.

Die Vortragsfolien mit einigen Latenzmustern sind online verfügbar.

Um die Optimierungsmöglichkeiten zu studieren, ist in Cambridge die freie Benchmark-Suite IPC-Bench entstanden. Anil Madhavapeddy bittet die Community, das Tool herunterzuladen und auf möglichst vielfältiger Hardware einzusetzen, um eine frei verfügbare Datenbank der Latenzen zusammenzustellen.

Zum Abschluss präsentierte er noch einen experimentellen Vorschlag zur Optimierung, den er als “Fable I/O” betitelte. Er soll die dynamische Rekonfiguration der IPC-Methoden je nach Hardware- und Software-Bedingungen ermöglichen. Als Beispiel führte der Referent eine Webanwendung in der Cloud an, die per TCP mit ihrer Datenbank kommuniziert. Das funktioniere zwar für alle Topologien, egal ob Datenbank und Anwendung auf dem selben oder auf unterschiedlichen Cloud-Knoten laufen, räumte er ein. Beim Betrieb auf dem selben Prozessor mit gemeinsamen Speicher ließen sich aber wesentliche leistungsfähigere Mechanismen verwenden.

Die dynamische Rekonfiguration und Optimierung würde Fable I/O durch einen zusätzlichen Flow Manager sowie einen Daemon umsetzen, der die Namen der Kommunikationsströme verwaltet. Der Programmierer würde dabei seine Ströme über ein einfaches API anmelden und benutzen, um die Auswahl der besten Kommunikationsmethoden kümmern sich dann die Daemons.