Linux-Magazin Clean Linux (Vorschau)

Aktuell
www.linux-magazin.de Kernel-News 09/2013
20
Schneller Booten auf Speicherriesen
Der SGI-Entwickler Nathan
Zimmer bemerkte, dass das
Booten auf Hochleistungsrechnern
mit viel Speicher sehr
lange dauert. Mit 16 TByte
RAM zum Beispiel kann es
über eine Stunde in Anspruch
nehmen, die hauptsächlich
beim Initialisieren des Arbeitsspeichers
vergeht. Ein Patch
von ihm und seinem Kollegen
Mike Travis sorgt dafür, dass
zuerst die CPUs starten. So
lässt sich die Speicherinitialisierung
auf mehrere Prozessoren
verteilen.
Greg Kroah-Hartman fiel auf,
dass die beiden ihr Patch als
Konfigurationsoption vorgesehen
hatten. Das hält er
für unnötig vorsichtig, denn
schließlich sei schnelleres
Booten stets ein Gewinn für
den Anwender. H. Peter Anvin
schloss sich diesem Argument
an und hält das Feature für
alle Rechner ab einer gewissen
RAM-Größe für sinnvoll,
geschätzt ab 28 GByte.
Daneben war Peter neugierig,
wie groß das Patch sei, und
Nathan antworte, es umfasse
nur 400 Codezeilen. Peter
hatte aber den binären Maschinencode
gemeint, und der
vergrößert das Kernelimage
um 32 KByte. Anvin hält das
für erstaunlich umfangreich.
„Ist das alles Initcode?“, fragte
er, „32 KByte Laufzeitcode,
der immer ausgeführt wird, ist
doch nicht ganz unproblematisch.“
Nathan Zimmer meinte,
echter Runtimecode seien
wohl nur 24 KByte.
Es folgte eine Diskussion über
alternative Umsetzungen der
Idee. Der x86-Kenner Yinghai
Lu brachte Anregungen ein
und Ingo Molnar schlug ein
ganz anderes Konzept vor, das
den Buddy-Allocator verwendet,
der den Speicher in kleinere
Einheiten aufteilt. Welche
Lösung sich auch durchsetzt,
die Besitzer großer Maschinen
dürfen sich wohl bald über
rascheres Booten freuen. n
Anonymous Memory von Android
Der Google-Entwickler Colin
Cross findet es schade, wenn
Features in »linux‐next« liegenbleiben.
Einige würde er
lieber im offiziellen Kernelzweig
sehen, insbesondere
»ashmem« (Android Shared
Memory), das mehrere Arten
von anonymem Arbeitsspeicher
umsetzen kann.
Besonders gefällt Colin Named
Anonymous Memory. Hinter
dieser Bezeichnung steckt
eine Speicherregion, die als
Datei unter »/proc/pid/maps«
auftaucht. Er schreibt: „Die
Dalvik-VM macht von diesem
Feature ausgiebig Gebrauch
[...]. Es erlaubt Speicher für
verschiedene Zwecke über
mehrere Prozesse hinweg zusammenzufassen.
Android benutzt
es in seinen Tools »dumpsys
meminfo« und »librank«,
um die Speichernutzung von
Java-Heaps, JIT-Caches und
anderem zu bestimmen.“
Christoph Hellwig schien zunächst
nicht davon überzeugt,
dass das Feature tatsächlich
so nützlich sei. Er verstand
nicht, „was »ashmem« besser
machen sollte als ein shared
»mmap« von »/dev/zero«“.
Colin erklärte ihm daher,
»ashmem« binde den Speicher
an einen Filedeskriptor.
Damit lasse er sich einem
anderen Prozess übergeben,
was mit »/dev/zero« nicht
funktioniere – es würde eine
neue Speicherregion herauskommen.
Christoph war zunächst
erstaunt, konsultierte
dann aber den Quelltext von
»/dev/zero« und gab Colin
schließlich recht.
Darauf folgte eine Diskussion
über Implementierungsdetails,
an denen sich auch John
Stultz vom Linaro-Projekt beteiligte.
Ein konkretes Konzept
ergab sich dabei zwar nicht,
aber dennoch scheint das
Android-Feature »ashmem«
ein aussichtsreicher Kandidat
für den Mainline-Kernel von
Linux zu sein.
n
32-Bit-Kernel auf 64-Bit-Hardware
Der Software-Entwickler Pierre-Loup
A. Griffais klagte,
das Kopieren von Dateien laufe
in letzter Zeit immer langsamer,
wenn man einen 32-Bit-
Kernel und mehr als 16 GByte
Arbeitsspeicher verwendet.
Darauf erwiderte Rik van Riel:
„Wenn du so viel Speicher in
deinem System hast, solltest
du einen 64-Bit-Kernel verwenden,
ansonsten treten im
Memory Management viele
Grenzsituationen auf.“ Johannes
Weiner fügte an: „Dabei
kannst du das 32-Bit-Userland
behalten, tausche einfach den
Kernel aus.“
Pierre-Loup antwortete: „Viele
Distributionen liefern einen
32-Bit-Kernel als Standard für
Anwender, die unsicher sind.
Dabei ist PAE aktiviert, um die
Mengen an Arbeitsspeicher in
modernen Rechnern zu unterstützen.“
Da konnte Linus Torvalds nicht
mehr an sich halten: „PAE ist
eine Notlösung. Das ganze
Konzept taugt nichts, und
alle, die einen 32-Bit-Kernel
mit 16 GByte RAM betreiben,
haben nicht die geringste Ahnung.
So etwas tut man nicht.
Sie sollen auf 64 Bit upgraden
oder sich mit der miesen I/​O-
Leistung abfinden.“ Er fügte
hinzu: „Beschwer dich bei
deiner Distribution, wenn sie
keinen 64-Bit-Kernel liefert.
Aber wir Kernelentwickler
werden uns nicht damit abmühen,
PAE zu optimieren. Es
lohnt sich einfach nicht.“
Er habe für sich persönlich
zwar einen 64-Bit-Kernel
kompiliert, räumte Pierre-
Loup ein, für viele seiner
Endanwender sei das aber
keine Option. „Ich werde die
Distributionen darauf hinweisen,
dass PAE-Kernel angesichts
der auftretenden Probleme
und der Einstellung der
Kernelentwickler keine gute
Standardlösung sind.“
Rik van Riel schlug schließlich
einen gangbaren Mittelweg
vor: „Man könnte den
Speicher, den ein PAE-Kernel
nutzt, auf eine bestimmte
Menge beschränken, bei der
es noch nicht zu Problemen
kommt, etwa 8 oder 12 GByte.
Daneben könnte der Kernel
eine Warnung ausgeben, die
dem Anwender mitteilt, er
solle auf einen 64-Bit-Kernel
upgraden, um seinen gesamten
Arbeitsspeicher zu nutzen.“
Das gefiel Pierre-Loup.
(Zack Brown/​mhu) n