Turbo für Embedded Linux
Tipps zur unkomplizierten Bootzeit-Optimierung
Fortsetzung des Artikels von Teil 1
Tipps zur unkomplizierten Bootzeit-Optimierung
Der Kernel
Liegt der Kernel schließlich im Speicher, wird dieser vom Bootloader angesprungen und beginnt, das System zu initialisieren. Auf einem konventionellen Distributions-Kernel, wie er z.B. auf einem Server zum Einsatz kommt, werden in der Regel alle möglichen Busse gescannt und nach Hardware durchsucht. Hier ergibt sich für Embedded- Systeme ein Vorteil: Die Hard- ware ist oft relativ starr und zudem im Vorhinein bekannt. Das ermöglicht es, einen optimierten Kernel zu konfigurieren, der lediglich die benötigten Komponenten beinhaltet. Das hat zwei Vorteile: Zum einen ist ein optimierter Kernel klein, was einem schnellen Laden vom Bootmedium zugute kommt. Zum anderen müssen nur diejenigen Hardware-Komponenten initialisiert werden, die für die initiale Funktion benötigt werden.
Dank der Möglichkeit des Kernels, nachträglich Module zu laden, können alle zusätzlichen Funktionen auch nach der „heißen“ Bootphase gestartet werden. Zudem können einzelne Treiber bereits mit vordefinierten Werten initialisiert werden, wenn sich diese auf dem dedizierten Embedded-System niemals ändern. Bei der Analyse der Bootzeiten stellt sich oft heraus, dass für gewisse Routinen im Kernel schmerzlich lange Delays eingestellt sind, etwa was das „Settlen“ von hotplug-fähigen Devices angeht. Da ist die Verlockung groß, diese Delays zu verkürzen, zudem oft festgestellt wird, dass die Hardware auch mit kürzeren Delays noch scheinbar zuverlässig funktioniert. Hier ist jedoch Vorsicht angebracht: Der Linux-Kernel beinhaltet eine Menge Erfahrungswissen derjenigen, die die entsprechenden Treiber geschrieben haben.
Typische Effekte sind, dass mit verkürzten Delays einige Speichergeräte nicht mehr funktionieren, oder auch dass Systeme nicht mehr zuverlässig sind, wenn der volle zulässige Temperaturbereich ausgeschöpft wird. Somit empfiehlt sich, Delays nur dann zu verändern, wenn alle möglichen Konsequenzen bedacht werden. Moderne Kernel-Versionen verfügen ferner intern über einen parallelisierten, asynchronen Startup mit Synchronisationspunkten, so dass die Ressourcen optimal ausgenutzt werden.
Optimierung im Anwendungsbereich
Hat der Kernel seine Initialisierungen der Hardware vorgenommen, startet er als ersten Prozess ein Programm namens /sbin/init. Auf gewöhnlichen Linux- Systemen handelt es sich hierbei um System V Init, eine lang etablierte Software zum Starten vieler Betriebssystem-Dienste wie Syslog- Server, NTP oder etwa FTP- und Webserver. Schließlich kann auch die eigene Applikation über System V Init gestartet werden. Obwohl System V Init den Vorteil der guten Standardisierung hat, bietet es für einen schnellen und reibungslosen Bootvorgang viele Nachteile. Insbesondere sind viele der Funktionalitäten in Shell geschrieben, was dazu führt, dass hunderte von Prozessen zunächst gestartet und gleich wieder beendet werden. Das erzeugt Last auf dem System, die vermeidbar ist. Weiterhin ist der Bootvorgang bei System V Init vollständig serialisiert: Einzelne Dienste, die Infrastruktur (etwa Netzwerk) bereitstellen, müssen zeitlich vor anderen Diensten (etwa einem Webserver) gestartet werden.
Jobangebote+ passend zum Thema
Bereits auf Single-Core-CPUs wird dieses sequenzielle Starten zum Flaschenhals. Gänzlich schlecht ausgenutzt sind jedoch moderne Multicore-Systeme wie diverse Atom- oder Cortex-A9-Derivate, bei denen in der Bootphase lediglich ein Core beschäftigt ist. Auf den derzeit am schnellsten bootenden Systemen wird /sbin/init direkt durch die Applikation ersetzt, so dass bereits zu Beginn der Ausführung des Userspace-Codes die Applikation zum Zuge kommen kann. Die Applikation kann dabei so umgesetzt werden, dass die sonstigen System-Dienste später noch nachträglich gestartet werden können. Ein Beispiel auf einem i.MX35-Prozessor von Freescale (ARM1136 EJ-S, 532 MHz) findet sich in Bild 2.
Gerade bei größeren Anwendungen, bei denen umfangreiche Software- Frameworks zum Einsatz kommen, spielt die Startzeit der Applikation ebenfalls eine wichtige Rolle. Andrew Murray hat kürzlich in einem Vortrag auf der ELC-E-Konferenz[3] gezeigt, wie der Start einer Qt-Applikation durch geschicktes Verteilen der Bibliotheksblöcke auf Flash-Blöcke auf unter eine Sekunde reduziert werden kann.
- Tipps zur unkomplizierten Bootzeit-Optimierung
- Tipps zur unkomplizierten Bootzeit-Optimierung
- Tipps zur unkomplizierten Bootzeit-Optimierung
