Von allen Computern, die ich je besessen oder benutzt habe, war derjenige aus den 1980er Jahren, der am schnellsten hochgefahren ist; Als sich Ihre Hand vom Netzschalter zur Tastatur bewegte, war der BASIC-Interpreter bereit für Ihre Befehle. Moderne Computer brauchen zwischen 15 Sekunden für einen Laptop und Minuten für einen kleinen Heimserver zum Hochfahren. Warum gibt es einen solchen Unterschied in den Startzeiten?
Ein Mikrocomputer aus den 1980er Jahren, der direkt mit einer BASIC-Eingabeaufforderung gestartet wurde, hatte eine sehr einfache CPU, die sofort nach dem Einschalten mit dem Abrufen und Ausführen von Anweisungen von einer Speicheradresse begann. Da diese Systeme BASIC im ROM hatten, gab es keine Ladezeit – Sie kamen sehr schnell zur BASIC-Eingabeaufforderung. Komplexere Systeme der gleichen Ära, wie der IBM PC oder Macintosh, brauchten eine beträchtliche Zeit zum Booten (~ 30 Sekunden), obwohl dies hauptsächlich darauf zurückzuführen war, dass das Betriebssystem (OS) von einer Diskette gelesen werden musste. Nur eine Handvoll Sekunden wurden in der Firmware verbracht, bevor ein Betriebssystem geladen werden konnte.
Moderne Server verbringen in der Regel Minuten statt Sekunden mit der Firmware, bevor sie an den Punkt kommen, an dem ein Betriebssystem von der Festplatte gebootet wird. Dies liegt vor allem an der gestiegenen Komplexität moderner Systeme. Eine CPU kann nicht mehr einfach hochfahren und mit der Ausführung von Anweisungen mit voller Geschwindigkeit beginnen; Wir haben uns an CPU-Frequenzskalierung, Leerlaufzustände, die viel Strom sparen, und mehrere CPU-Kerne gewöhnt. Tatsächlich befinden sich in modernen CPUs überraschend viele einfachere CPUs, die dabei helfen, die Haupt-CPU-Kerne zu starten und Laufzeitdienste bereitzustellen, wie z. B. das Drosseln der Frequenz, wenn es zu heiß wird. Auf den meisten CPU-Architekturen wird der Code, der auf diesen Kernen innerhalb Ihrer CPU ausgeführt wird, als undurchsichtige binäre Blobs bereitgestellt.
Auf OpenPOWER-Systemen ist jede Anweisung, die auf jedem Kern innerhalb der CPU ausgeführt wird, Open-Source-Software. Auf Maschinen mit OpenBMC (wie dem AC922-System von IBM und den Systemen TALOS II und Blackbird von Raptor) erstreckt sich dies auch auf den Code, der auf dem Baseboard Management Controller ausgeführt wird. Das bedeutet, dass wir einen enormen Einblick in die Zeit bekommen, die vom Einstecken eines Netzkabels bis zur Anzeige einer vertrauten Anmeldeaufforderung so lange dauert.
Wenn Sie Teil eines Teams sind, das am Linux-Kernel arbeitet, booten Sie wahrscheinlich viele Kernel. Wenn Sie Teil eines Teams sind, das an Firmware arbeitet, werden Sie wahrscheinlich viele verschiedene Firmware-Images booten, gefolgt von einem Betriebssystem, um sicherzustellen, dass Ihre Firmware weiterhin funktioniert. Wenn wir die Bootzeit der Hardware verkürzen können, können diese Teams produktiver werden, und die Endbenutzer sind möglicherweise dankbar, wenn sie Systeme einrichten oder neu starten, um Firmware- oder Betriebssystemaktualisierungen zu installieren.
Programmierung und Entwicklung
- Red Hat Entwickler-Blog
- Spickzettel programmieren
- Kostenlos testen:Red Hat Learning Subscription
- eBook:Eine Einführung in die Programmierung mit Bash
- Bash-Shell-Scripting-Spickzettel
- eBook:Modernisierung von Enterprise Java
Im Laufe der Jahre wurden viele Verbesserungen an der Bootzeit von Linux-Distributionen vorgenommen. Moderne Init-Systeme kommen gut damit zurecht, Dinge gleichzeitig und nach Bedarf zu erledigen. Auf einem modernen System kann es nach Beginn der Ausführung des Kernels nur wenige Sekunden dauern, bis eine Anmeldeaufforderung angezeigt wird. Diese wenigen Sekunden sind nicht der richtige Ort, um die Startzeit zu optimieren; wir müssen früher gehen:bevor wir zum Betriebssystem kommen.
Auf OpenPOWER-Systemen lädt die Firmware ein Betriebssystem, indem sie einen Linux-Kernel bootet, der im Firmware-Flash-Chip gespeichert ist, der ein Userspace-Programm namens Petitboot ausführt, um die Festplatte zu finden, auf der sich das Betriebssystem befindet, das der Benutzer booten möchte, und kexec() darauf. Diese Code-Wiederverwendung nutzt die Anstrengungen, die unternommen wurden, um das Booten von Linux schneller zu machen. Trotzdem haben wir in unserer Kernel-Konfiguration und im Userspace Stellen gefunden, an denen wir die Startzeit verbessern und auf einfache Weise Sekunden verkürzen konnten. Mit diesen Optimierungen macht das Booten der Petitboot-Umgebung einen einstelligen Prozentsatz der Bootzeit aus, sodass wir an anderer Stelle nach weiteren Verbesserungen suchen mussten.
Bevor die Petitboot-Umgebung startet, gibt es ein vorheriges Stück Firmware namens Skiboot, und davor gibt es Hostboot. Vor dem Hostboot befindet sich die Self-Boot-Engine, ein separater Kern auf dem Chip, der einen einzelnen CPU-Kern hochfährt und Anweisungen aus dem Level-3-Cache ausführt. Mit diesen Komponenten können wir den größten Fortschritt bei der Verkürzung der Startzeit erzielen, da sie den überwiegenden Teil davon einnehmen. Vielleicht sind einige dieser Komponenten nicht genug optimiert oder machen nicht so viel parallel, wie sie könnten?
Ein weiterer Angriffspunkt ist die Neustartzeit und nicht die Startzeit. Bei einem Neustart tun wir das wirklich müssen alle neu initialisieren die Hardware?
Wie bei jedem modernen System waren die Lösungen zur Verbesserung der Start- (und Neustart-) Zeit eine Mischung aus mehr Parallelität, dem Umgang mit Altlasten und (wohl) Betrug.
Stewart Smith wird vom 21. bis zum 25. Januar in Christchurch, Neuseeland, auf der linux.conf.au einen Vortrag zum schnelleren Booten halten.