Der Linux-Kongress fand dieses Jahr in Nürnberg statt, in der FH Nürnberg, in einem sehr schönen Gebäude mit schönen Hörsälen mit hellem Holz und Deckenfenstern, sehr angenehm. Die Keynote von Alan Cox beschäftigte sich mit 3d Printern, und der Idee, daß diese Geräte sich selber replizieren, mit Holodecks, und mit der Frage, wie unsere Gesetzgebung damit umgehen soll. Wie schützt man einen Stuhl mit Copyright? Was für Lizenzen braucht man, um im Holodeck ein Coca Cola Logo zu zeigen? Sehr nette Keynote. Mein eigener Vortrag über die Benchmarks lief gut, aber der Beamer mochte meinen VGA-Ausgang nicht, und zeigte nur die linke Hälfte. Also habe ich in den letzten 10 Minuten vor dem Vortrag noch mit Modelines gefummelt, und geguckt, ob das als Notfallmaßnahme unter Windows geht, ging aber auch nicht. So habe ich dann am Ende Heinz Mauelshagens Notebook benutzt, und meine PDF-Folien per USB Stick von da gezeigt. Eine der Hoffnungen bei den Benchmarks war ja, daß das hochkarätige Publikum vielleicht gleich ein paar der merkwürdigen Messungen erklären könnte, und so war es dann auch. Ted T'so wunderte sich initial auch, daß ext2 so viel langsamer als ext3 war, aber dann fiel ihm auf, daß ext2 das Directory Hashing nicht implementiert (because it's unsafe without journaling). Andi Kleen hat mich dann noch korrigiert, daß VFS inzwischen gar nicht mehr einen großen Lock hat, und tatsächlich mehr als ein Request parallel beim Filesystem ankommen können. Um so erstaunlicher dann, daß Linux nicht mehr Lesedurchsatz kriegt, wenn mehr als ein Prozess parallel Dateien zu öffnen und lesen versucht. Ich habe auch eine nette Diskussion mit Alan Cox, Daniel Phillips und Jeff Dike über AIO gehabt. Ich hätte ja für gatling gerne eine Möglichkeit, asynchron Dateien aufzumachen, damit gatling nicht auf open blockt. Und ich habe eine durchaus interessante Antwort gekriegt. Das open im Kernel ist keine State Machine, sondern eine fundamental iterative Routine, d.h. wenn der Kernel jetzt open asynchron implementieren wollte, dann würde der Kernel das über einen Thread pro asynchroner open-Anfrage machen. Und wenn man diese Aussage akzeptiert, dann wird klar, daß man das auch im User Space machen kann. Alan Cox meinte dann noch, daß die Threads kürzlich deutlich optimiert wurden, und daß bei Linux das Erzeugen eines Threads so billig ist, daß es weniger kostet als ein Signal zuzustellen. Das ist schon eine echt krasse Aussage, an das Modell muß man sich erst mal gewöhnen. Das, und die Tatsache, daß Linux einen O(1) Scheduler hat, heißt für mich, daß ich mich doch mal mehr mit Threads beschäftigen muß, auch wenn ich Threads fundamental nicht mag. Das heißt auch, daß wir für die diet libc mal ein modernes Threadsystem implementieren müssen, mit Thread Local Storage. Sollte an sich nicht so schwierig sein, denn die meisten Thread-Funktionen werden inzwischen ziemlich direkt auf Syscalls abgebildet. Und es gibt da ja sehr interessante Optionen, mit Futexen und so. Werde ich mir mal in Ruhe angucken müssen. Jeff Dike ist der Maintainer von User Mode Linux, und darüber hatte er auch einen Talk. Es gibt da ein lustiges Problem, weshalb ich mich überhaupt mit ihm über AIO (asynchrones I/O, falls das jemandem nicht klar ist) unterhalten habe. Was, wenn man ein Hostsystem mit Swapping hat, und in dem Hostsystem laufen ein paar virtuelle Maschinen, die auch Swappen. Nun nehmen wir mal an, daß der RAM knapp ist, und daß eine VM eine Page rausswappen will. Dafür faßt es die Page noch einmal an. Wenn die Seite rausgeswappt wird, dann ist sie eine Weile nicht angefaßt worden, d.h. die Seite ist auch im Host raus geswappt. D.h. sowohl die VM als auch der Host swappen die Seite jetzt rein, von der sich eigentlich alle einig sind, daß sie unwichtig ist, d.h. neben dem überflüssigen Overhead ist die Seite jetzt auch ganz oben auf der Last Recently Used Liste. Die Lösung von UML? Sie benutzen O_DIRECT! D.h. der Cache im Host wird komplett abgeschaltet für VM-Speicher. Wenn jetzt zwei UMLs die gleichen Dateien mmappen, dann gibt es daher Speicher-Verschwendung und der Cache im OS hilft nicht. Außerdem ist das so, weil (haltet euch fest) AIO auf Druck von Oracle gemacht wurde, und Oracle benutzt O_DIRECT für ihre Partitionen und Dateien, und daher supported AIO im Moment nur O_DIRECT. Sie arbeiten aber wohl gerade an AIO für buffered data. Oh, noch was zu ext3: Ted T'so meinte, daß die allerneuesten e2fsprogs per Default ein größeres Journal anlegen und Directory Indexes anschalten, und er glaubt, daß das größere Journal die Pausen im Durchsatz senken sollte. Muß ich mal testen. Ich habe mich dann noch mit Andi Kleen unterhalten, wieso das denn nicht schneller wird, wenn es doch keinen großen Lock im VFS gibt, und er meinte, ich solle mal ein paar andere I/O Scheduler ausprobieren und Jens Axboe ansprechen. Andere Vorträge waren hier noch über RAID von Heinz Mauelshagen (hatte jetzt keine schockierenden Neuigkeiten zu übermitteln), und einer über iSCSI (hat mich auch nicht so vom Hocker gehauen, wobei auch nicht klar ist, was man zu solchen Themen faszinierendes erzählen soll). Am Abend habe ich das Social Event verpaßt, weil zwei alte Freunde zufällig unabhängig von einander in der Stadt waren, und so sind wir zusammen einen Heben gegangen :-) Am zweiten Tag hatte Ted T'so eine schöne Keynote über Linux, das nächste Woche oder so 15jährigen Geburtstag hat, wenn man ab dem Erscheinen des 0.1 Tarballs auf tsx-11.mit.edu rechnet (und den hat Ted betrieben, daher konnte er aus den Logs das Datum rekonstruieren). Er hatte Folien mit verschiedenen Daten und was dann passiert ist, u.a. daß Slashdot erst 1997 aufgemacht hat, und daß DEC schon 1994 einen Alpha-Port von Linux unterstützt hat. Später ging es dann um die Neuerungen, was noch so zu erwarten ist, und Ted meinte, die großen Werke seien im Grunde fertig. Seit zwei Jahren gehen alle davon aus, daß demnächst die 2.7 Serie gestartet wird, aber bisher kam noch kein so großer Patch, daß es sich gelohnt hätte. :-) Ted meinte, es gibt natürlich immer noch Sachen zu tun, neue Treiber, neue Bussysteme, insofern bleibt die Entwicklung jetzt nicht stehen, aber sie haben im Großen und Ganzen erreicht, was sie erreichen wollten. Einer der Vorträge, auf die ich mich am meisten gefreut habe, ist der von Andi Kleen über Speicher, insbesondere wo bei 2.6 Kernels eigentlich der ganze Speicher hingeht. Er fing damit an, daß Speichersparen früher Leute interessiert hat, als alle wenig Speicher hatten. Er glaubt nicht, daß noch Leute Sachen auf alten Kisten fahren, und dann neue Kernels haben, auf alter Hardware läuft üblicherweise auch alte Software. Auch den embedded-Bereich findet er nicht interessant, weil die Leute ja ihre Kernels tunen können. Aber was gerade die Problemstellung voran treibt ist die Virtualisierung, insbesondere S/390, weil die Leute da auf einem Host viele Gäste mit jeweils 128 MB laufen lassen wollen, oder sogar nur 64 MB, und die sind dann halt unzufrieden, wenn das nicht gut performt. Andi hatte einige schöne Statistiken, wie viel Speicher in System so für Page Tables drauf geht. Er meinte, wenn er auf seinem SLES10 GNOME mit Firefox startet, dan hat er schon mal 5,3 MB Speicher nur für Page Tables ausgegeben. Man hat pro Page ungefähr 8,2 Bytes Overhead (ist ne Baumstruktur), und pro Thread hat man 8K Overhead für Kernel Stacks, das sind auf seinem Testsystem ungefähr 1 MB. Dann haben sie einen Hack, wo sie Pages voralloziert haben, weil das Freigeben von Speicher mehr Speicher brauchen kann (z.B. wenn man was über NFS rausschreiben will, und für die Pakete Platz braucht). Das sind bei ihm nur 480 KB, aber er meint, daß das auf größeren Systemen auch mehr ist. Der Slab Allokator ist wohl ziemlich kraß optimiert, NUMA-aware, mit pro-CPU Caches, Cache Coloring, aber an sich wohl nicht so weit von dem weg, was die diet libc macht, nämlich für einige feste Größen eine Liste mit Blöcken dieser Größe, so daß man beim Allozieren nur den ersten nehmen muß, und nicht irgendwelche Listen langlaufen muß. kmalloc sitzt auf dem Slab Allocator drüber, aber ist offenbar so komplex, daß das keiner mehr versteht. Die Kernel Pages an sich werden mit einem Buddy Allokator alloziert, und bei lange laufenden Systemen gibt es da Fragmentierungsprobleme. Linux ist wohl ziemlich agressiv beim Cachen von dentries (Verzeichniseinträgen), und die Einträge werden nur rausgeschmissen, wenn der Platz wirklich für was anderes gebraucht wird. Sein Lieblingsbloatfeind im Kernel sind Hashtabellen. Er meint, auf seinem System sind über 4 MB Hashtabellen im Kernel, und die wachsen mit der RAM-Größe. 4 MB ist nicht viel, aber wenn man es mit der Kernelcodegröße vergleicht, ist es fast genau so groß wie der Kernel. Es lohnt sich also viel mehr, die Datenstrukturen zu optimieren, als im Kernelcode zu optimieren. Er brachte noch ein sehr interessantes Argument zu Hashtabellen. Normalerweise versucht man, die Hashtabelle groß zu machen, damit man dahinter keine langen Listen langlaufen muß. Sein Argument ist jetzt, daß man sich damit aber einen Cache Miss erkauft beim Hashzugriff, und ein Zugriff auf den Hauptspeicher kostet so viel, daß man in der Zeit Dutzenden von Knoten in einem Baum hinterher laufen kann. Stimmt nicht ganz, denn bei Bäumen hat man unvorhersagbare conditional jumps, die kosten auch ein bißchen, wenn auch eine Größenordnung weniger. http://www.firstfloor.org/~andi/memory{,waste}.pdf In der Pause vor dem nächsten Vortrag gab es noch ein lustiges Detail, als Marcel Holtmann (Mr. Bluetooth) Ted mit einem coolen Mini-WLAN-AP (Footprint ungefähr so groß wie ein Notebook-Touchpad) beeindrucken wollte, und Ted dann einmal in seine Tasche griff und zwei Kulturbeutel-große Säckchen mit Geek Toys rausholte, und nicht nur hatte er auch so einen WLAN-AP, er hatte da einen universellen Stromumstecker, der mich ein bißchen an Rubik's Cube erinnert hat, wo er da flink Teile zusammen steckte, und aus den selben zwei winzigen Elementen Stromumstecker für 12 Länder gebastelt hat. Also ich war beeindruckt :-) Ted hat da alle anderen mit großem Abstand outgeeked. Dann war da noch ein besonders cooler universeller Dreifach-Steckdosen-Verlängerer und ein paar Dinge, die ich schon wieder verdrängt habe. Ein weiteres sehr lustiges Detail war, als sich ein ad-hoc PGP Keysigning zwischen Volker Lendecke und einer Amerikanischen Google-Mitarbeiterin ergab. Volker legte ihr seinen Ausweis vor, sie guckt ihn sich an, und meinte lächelnd "Bielefeld? I thought that doesn't exist." Da fiel am Tisch einigen die Kinnlade runter... Sie hatte offenbar ein paar Jahre in München gewohnt und kannte das daher. Noch ein Alan Cox Zitat zum Nachdenken: der Speicher ist heute zu langsam im Vergleich zum CPU-Cache, daß man anfangen muß, das wie einen Plattenzugriffe zu behandeln mental. Der vorletzte Vortrag für mich ist von Ted T'so über Real-Time Linux. Driving Force hinter Real-Time Linux ist... Real-Time Java! "Please don't laugh too hard" :-) Ted meint, daß die Leute heute Real-Time CORBA haben wollen! Bei heutiger Hardware kann man gar keine tiefschürfenden Analysen mehr machen, wie man sie für echte Real-Time Aussagen brauchen würde, und wenn man Kunden fragt, wie viel Latenz sie gerade noch tolerieren können, dann sagen die alle entweder "so wenig wie möglich" oder sie nennen einem eine Zahl, die in ihrem Kopf so zustande gekommen ist, daß sie die kleinste Zahl nennen, die sie für überhaupt erreichbar halten. Der große Markt für Real-Time Sachen im Moment sind so Enterprise Lösungen, wo Anbieter für ihre Webanwendungen Antwortzeiten im Bereich von einer halben Sekunde oder so garantieren wollen, und da geht es gar nicht so um den Fall, den man traditionell mit Real-Time assoziiert (nämlich daß selbst wenn alle möglichen Probleme gleichzeitig passieren, man die Zeitvorgabe noch einhalten kann). Das Beispiel war, daß in vielen Fällen schon das Cluster Quorum ne halbe Minute braucht, und das alle Garantien kaputt macht. Kurz: normalerweise geht es dem Markt heute nicht um die Summe der Worst Cases aller Subsysteme, sondern um die Summe der Durchschnittsfälle plus Sicherheitsrahmen. Cooles Detail (war mir gestern schon aufgefallen beim Updaten der syscalls.h in der diet libc): Linux supported seit ein paar Tagen priority inversion für Futexe, d.h. wenn ein High Priority Prozeß (oder gar ein Real-Time Prozess) auf einen Mutex wartet, den ein Low Priority Prozeß hält, daß dessen Priorität dann kurzfristig auf das Niveau des höchsten wartenden Prozesses erhöht wird. Sie haben auch gerade die meisten Spinlocks im Kernel in "sleeping spinlocks" gewandelt, d.h. da kann dann ein High Priority Prozeß reingeschoben werden. Und das exponierte plötzlich alle möglichen Bugs im Locking, denen Ingo Molnar dann hinterher laufen mußte :-) IBM hat jetzt offenbar ein Real-Time Java gehackt, und da gibt es auch einen Sun Standard für, der allerdings keinen Real-Time Garbage Collector vorschreibt! Dafür definieren sie "no-heap real-time threads with scopes", das sind dann die "echten" Real-Time Threads, die keinen Speicher auf dem Heap benutzen dürfen, weil die vom Garbage Collector gelockt oder rumgeschoben werden dürfen. Das heißt, daß man praktisch keinen Stock Java Code benutzen kann. Warum braucht man überhaupt Real-Time Java? Das Militär verlangt das! Weil sie keine Ada-Programmierer finden, steigen die gerade auf Java um, und für ihre Waffensysteme wollen die Real-Time in ihrem Java haben. OMFG. Kommentare aus dem Publikum: "does that mean that Java is now dying, too?" :-) Im Moment gibt es da noch größere Durchsatzprobleme (Real-Time Systeme erkaufen sich immer kleinere Latenzen auf Kosten von Durchsatz), Anwender der Patches haben da wohl teilweise Regressionen von einem Faktor 20 gesehen.