Open Source im professionellen Einsatz
Linux-Magazin 08/2014

Zacks Kernel-News

1001

Ein Häppchen Echtzeit für die Datenbank

Khalid Aziz von Oracle hat einen kontroversen Vorschlag eingebracht. Er möchte dem Kernel eine Portion Echtzeitcode hinzufügen, um ein Problem zu lösen, auf das seine Datenbank-Kollegen gestoßen sind. In seinem Szenario schnappt sich ein Thread einen Mutex, doch dann läuft seine Zeitscheibe ab, bevor er ihn wieder freigibt. Der nächste Thread versucht sich den Mutex zu greifen, rotiert eine Weile untätig und gibt schließlich auf. Das geht so lange, bis der erste Thread wieder CPU-Zeit erhält, seinen kritischen Abschnitt abarbeitet und den Mutex freigibt.

Khalid berichtet, andere Betriebssysteme lösten das Problem, indem sie einem Thread erlauben eine zusätzliche Zeitscheibe zu beantragen. Diese gibt ihm Zeit, das Lock freizugeben, so müssen die anderen Threads nicht Schlange stehen. Ein ähnliches Feature in Linux könnte Datenbanken seiner Einschätzung nach um drei bis fünf Prozent schneller machen.

Er schickte ein Patch an die Mailingliste, das auf Code des Google-Entwicklers Venkatesh Pallipadi beruht. Es legt für jeden Prozess eine Pseudodatei im Proc-FS an. Schreibt ein Thread den Wert 1 in die im zugeordnete Datei, erhält er die ganze verfügbare CPU-Zeit, bis er eine 0 hineinschreibt. Davidlohr Bueso von Hewlett-Packard hat an dem Feature an sich nichts auszusetzen, findet es aber in einer der Echtzeit-Varianten von Linux besser am Platz als im Mainline-Kernel.

Khalid erwiderte darauf, die Datenbank benötige keine komplette Echtzeitunterstützung und auch keine vollständige Kontrolle über die Ressourcen. Es gehe ausschließlich um jenen kurzen Moment mit Locking, in dem eine kleine Änderung viel Zeit sparen könnte.

H. Peter Anvin kommentierte die Änderungen, die das Patch am Scheduling vornimmt. Er sieht Missbrauchspotenzial: Es erlaube dem Userspace, das preemptive Multitasking des Kernels, bei dem das Betriebssystem entscheidet, in ein kooperatives Multitasking zu verwandeln, bei dem Userland-Software dem Kernel signalisiert, wann sie die Kontrolle übergeben möchte.

Der deutsche Embedded-Entwickler Thomas Gleixner ging in Opposition zur ganze Idee hinter Khalids Patch: "Eine furchtbare Idee. Das wird ein zeitorientiertes Priority-Ceiling-Protokoll, das auf Wahrsagerei beruht und dazu noch die schlechteste Userspace-Schnittstelle besitzt, die ich je gesehen habe." Andi Kleen antwortete Thomas und forderte ihn auf, selbst eine bessere Lösung vorzuschlagen. Andi findet, von ähnlichen Problemen seien viele Workloads betroffen, und schreibt: "Ich habe schon einige Workarounds gesehen, und die meisten sind viel schlechter als dieses Patch." Die Mailingliste diskutierte Alternativen zu Khalids Code.

Ein Problem besteht darin, dass es um einen sehr kurzen Zeitabschnitt geht. Das Context Switching der CPU geschieht unzählige Male pro Sekunde. Jeglicher Code müsste daher innerhalb einer einzige Zeitscheibe ablaufen. Oleg Nesterov von Red Hat schlug vor, die anderen Prozesse sollten jenem mit dem Lock ihre CPU-Zeit spendieren. So würden sie nicht unnötig im Wartestand rotieren und der Prozess erhalte Zeit, den Mutex freizugeben.

Khalid winkte ab: "Bis ein Thread herausfindet, dass er das Lock nicht sperren kann, weil es noch ein anderer besitzt, ist schon die Zeit für einen Kontextwechsel vergangen." David Lang antwortete, das koste zwar einen Context Switch oder zwei, sei aber viel wirtschaftlicher als die Ausgangssituation mit den wartenden Threads.

Khalid zeigte sich überzeugt, dass eine Menge Anwendungen von seinem Vorschlag profitieren könnten. Daneben reichte er eine überarbeitete Version seines Codes ein. An diesem Punkt schrieb Andrew Morton, das Feature mache einen guten Eindruck, doch es fehlten noch praxisnahe Benchmarks.

Da schaltete sich wieder Davidlohr Bueso ein und berichtete, auf dem "Linux Storage Filesystem and MM Summit" im kalifornischen Napa Valley sei das Problem ebenfalls diskutiert worden. Ein solches Feature stehe beispielsweise auf dem Wunschzettel von Facebook und PostgreSQL. Offenbar findet die Idee weitere Anhänger, was gute Chancen für die Aufnahme des zugehörigen Codes in den Linux-Kernel erwarten lässt.

Dieses Patch schraubt am Scheduling, um Datenbanken schneller zu machen.

Mehr Ordnung für Systemcalls

Andy Lutomirski, Kernelentwickler aus der Finanzbranche, hält die Linux-Systemaufrufe für einen Wahnsinn. Insbesondere findet er es unmöglich, sie architekturübergreifend zu verwenden. Er beklagt, dass es keine saubere Methode gebe, die Syscall-Namen den -Nummern zuzuordnen oder den Registern die Argumente. Schwer sei auch zu verfolgen, welche Architekturen welche Systemcalls implementieren.

Der aktuelle Quelltextbaum des Kernels bilde das alles zwar nach Architekturen sortiert ab, aber ansonsten sehr chaotisch, klagt Andy. Funktionierende Zuweisungen finde man in Strace, Libseccomp und Glibc, aber auch dort fehle Systematik.

"Am liebsten wäre mir eine Master-Liste im Kernel, die für jeden Syscall dessen Namen und Nummer in jeder Architektur (in »AUDIT_ARCH« -Semantik) und seine Signatur verzeichnet. Der Buildprozess würde diese Tabelle verarbeiten und so das derzeitige Chaos ablösen", schreibt er und betont: "Vor allem könnten wir dem Tools-Verzeichnis eine Bibliothek hinzufügen, die diese Informationen dem Userspace zur Verfügung stellt."

Diese Idee gefällt Eric Paris von Red Hat hervorragend. Derzeit müssten Userspace-Tools so etwas auf eigene Faust umsetzen, beklagt er. Eine zentrale Liste findet er viel besser. Sein Firmenkollege Paul Moore pflichtet ihm bei und merkt an, auch die Umsetzung der Aufrufe in der Bibliothek Libseccomp sei fürchterlich und unwartbar: "Ich wäre wirklich dankbar, wenn der Kernel einen Header, eine Datei oder sonst was hätte, das Userspace-Anwendungen benutzen könnten, um Syscall-Namen und -Nummern für alle Architekturen einander zuzuordnen." Er fügt hinzu: "Eine Verbesserung an dieser Stelle könnte uns allen das Leben leichter machen, und ich würde mich nicht mehr zieren Andys Patches einzupflegen."

David Howells befürwortet Andys Vorschlag ebenso und meint: "Es wäre wirklich toll, wenn wir das so anlegen könnten, dass man daraus das Tool »strace« bauen kann." Andy und Peter diskutieren, wie man die erforderlichen Informationen zusammenträgt, und Michael Kerrisk, Betreuer der Kernel-Manpages, signalisierte ebenfalls Interesse. (Zack Brown/mhu)

Die Kernel-Manpages bemühen sich, die Syscalls zu dokumentieren. Eine maschinenlesbare Quelltextdatei wäre aber praktischer.

Diesen Artikel als PDF kaufen

Express-Kauf als PDF

Umfang: 2 Heftseiten

Preis € 0,99
(inkl. 19% MwSt.)

Linux-Magazin kaufen

Einzelne Ausgabe
 
Abonnements
 
TABLET & SMARTPHONE APPS
Bald erhältlich
Get it on Google Play

Deutschland

Ähnliche Artikel

  • Kernel-News
  • Kernel-News

    Zacks Kernel-News

  • Kern-Technik

    Manche Applikationen müssen verhindern, dass die CPU bestimmte Codesequenzen mehrfach betritt. Dazu aktivieren sie Realtime-Mutexe im Kernel. Die sind nicht nur besonders effizient, sondern beherrschen auch die für Echtzeitanwendungen wichtige Prioritätsinversion.

  • Sauber eingefädelt

    Der Standard für Threads unter Linux ist heute die Native Posix Threads Library (NPTL). Die Bibliothek überzeugt durch große Kompatibilität zum Standard und hohe Performance. Dieser Artikel untersucht die neue Threading-Engine und zeigt, wie Benutzeranwendungen davon profitieren.

  • Kernel-News
comments powered by Disqus

Stellenmarkt

Artikelserien und interessante Workshops aus dem Magazin können Sie hier als Bundle erwerben.