De tous les ordinateurs que j'ai possédés ou utilisés, celui qui a démarré le plus rapidement date des années 1980; au moment où votre main est passée de l'interrupteur d'alimentation au clavier, l'interpréteur BASIC était prêt pour vos commandes. Les ordinateurs modernes prennent entre 15 secondes pour un ordinateur portable et quelques minutes pour démarrer un petit serveur domestique. Pourquoi y a-t-il une telle différence dans les temps de démarrage ?
Un micro-ordinateur des années 1980 qui démarrait directement à une invite BASIC avait un processeur très simple qui commençait à récupérer et à exécuter des instructions à partir d'une adresse mémoire immédiatement après avoir été alimenté. Étant donné que ces systèmes avaient BASIC dans la ROM, il n'y avait pas de temps de chargement - vous êtes arrivé à l'invite BASIC très rapidement. Les systèmes plus complexes de la même époque, tels que l' IBM PC ou le Macintosh , prenaient beaucoup de temps pour démarrer (~ 30 secondes), bien que cela soit principalement dû au fait de devoir lire le système d'exploitation (OS) sur une disquette. Seules quelques secondes ont été passées dans le firmware avant de pouvoir charger un système d'exploitation.
Les serveurs modernes passent généralement des minutes, plutôt que des secondes, dans le micrologiciel avant d'en arriver au point de démarrage d'un système d'exploitation à partir du disque. Cela est dû en grande partie à la complexité accrue des systèmes modernes. Un processeur ne peut plus simplement démarrer et commencer à exécuter des instructions à pleine vitesse ; nous nous sommes habitués à la mise à l'échelle de la fréquence du processeur, aux états d'inactivité qui économisent beaucoup d'énergie et à plusieurs cœurs de processeur. En fait, les processeurs modernes contiennent un nombre surprenant de processeurs plus simples qui aident à démarrer les principaux cœurs de processeur et fournissent des services d'exécution tels que la limitation de la fréquence lorsqu'il fait trop chaud. Sur la plupart des architectures de CPU, le code s'exécutant sur ces cœurs à l'intérieur de votre CPU est fourni sous forme de blobs binaires opaques.
Sur les systèmes OpenPOWER, chaque instruction exécutée sur chaque cœur à l'intérieur du CPU est un logiciel open source. Sur les machines avec OpenBMC (telles que le système AC922 d'IBM et les systèmes TALOS II et Blackbird de Raptor), cela s'étend également au code exécuté sur le contrôleur de gestion de la carte mère. Cela signifie que nous pouvons obtenir un aperçu considérable de ce qui prend si longtemps entre le moment où vous branchez un câble d'alimentation et le moment où une invite de connexion familière s'affiche.
Si vous faites partie d'une équipe qui travaille sur le noyau Linux, vous démarrez probablement beaucoup de noyaux. Si vous faites partie d'une équipe qui travaille sur le micrologiciel, vous allez probablement démarrer de nombreuses images de micrologiciel différentes, suivies d'un système d'exploitation pour vous assurer que votre micrologiciel fonctionne toujours. Si nous pouvons réduire le temps de démarrage du matériel, ces équipes peuvent devenir plus productives et les utilisateurs finaux peuvent être reconnaissants lorsqu'ils configurent des systèmes ou redémarrent pour installer des mises à jour du micrologiciel ou du système d'exploitation.
Programmation et développement
- Blog des développeurs Red Hat
- Fiches de triche de programmation
- Essayez gratuitement :Red Hat Learning Subscription
- eBook :Une introduction à la programmation avec Bash
- Aide-mémoire pour les scripts de shell bash
- eBook :Modernisation de Java d'entreprise
Au fil des ans, de nombreuses améliorations ont été apportées au temps de démarrage des distributions Linux. Les systèmes d'initialisation modernes gèrent bien les tâches simultanées et à la demande. Sur un système moderne, une fois que le noyau commence à s'exécuter, quelques secondes peuvent être nécessaires pour accéder à une invite de connexion. Ces quelques secondes ne sont pas l'endroit pour optimiser le temps de démarrage; nous devons y aller plus tôt :avant d'arriver au système d'exploitation.
Sur les systèmes OpenPOWER, le micrologiciel charge un système d'exploitation en démarrant un noyau Linux stocké dans la puce flash du micrologiciel qui exécute un programme d'espace utilisateur appelé Petitboot pour trouver le disque contenant le système d'exploitation que l'utilisateur souhaite démarrer et kexec(). Cette réutilisation du code tire parti des efforts déployés pour accélérer le démarrage de Linux. Même ainsi, nous avons trouvé des endroits dans la configuration de notre noyau et dans notre espace utilisateur où nous pouvions améliorer et gagner facilement des secondes sur le temps de démarrage. Avec ces optimisations, le démarrage de l'environnement Petitboot représente un pourcentage à un chiffre du temps de démarrage, nous avons donc dû trouver d'autres améliorations ailleurs.
Avant le démarrage de l'environnement Petitboot, il existe un micrologiciel appelé Skiboot, et avant cela, il y a Hostboot. Avant Hostboot se trouve le moteur d'auto-amorçage, un cœur séparé sur la matrice qui obtient un seul cœur de processeur et exécute des instructions à partir du cache de niveau 3. Ces composants sont ceux où nous pouvons faire le plus de progrès dans la réduction du temps de démarrage, car ils en occupent l'écrasante majorité. Certains de ces composants ne sont peut-être pas suffisamment optimisés ou ne fonctionnent pas autant en parallèle qu'ils pourraient l'être ?
Une autre voie d'attaque est le temps de redémarrage plutôt que le temps de démarrage. Lors d'un redémarrage, avons-nous vraiment besoin de réinitialiser tous le matériel ?
Comme tout système moderne, les solutions pour améliorer le temps de démarrage (et de redémarrage) ont consisté à faire plus en parallèle, à gérer l'héritage et (sans doute) à tricher.
Stewart Smith présentera Booting Faster à linux.conf.au, du 21 au 25 janvier à Christchurch, Nouvelle-Zélande.