De todas las computadoras que he tenido o usado, la que arrancó más rápido fue la de la década de 1980; en el momento en que su mano se movió del interruptor de encendido al teclado, el intérprete BASIC estaba listo para sus comandos. Las computadoras modernas tardan desde 15 segundos para una computadora portátil hasta minutos para que arranque un pequeño servidor doméstico. ¿Por qué hay tanta diferencia en los tiempos de arranque?
Una microcomputadora de la década de 1980 que arrancaba directamente con un indicador BÁSICO tenía una CPU muy simple que comenzaba a buscar y ejecutar instrucciones desde una dirección de memoria inmediatamente después de recibir energía. Dado que estos sistemas tenían BASIC en la ROM, no hubo tiempo de carga:llegó al indicador de BASIC muy rápido. Los sistemas más complejos de esa misma época, como IBM PC o Macintosh, tardaban bastante en arrancar (~30 segundos), aunque esto se debía principalmente a tener que leer el sistema operativo (SO) de un disquete. Solo se gastaron unos pocos segundos en el firmware antes de poder cargar un sistema operativo.
Los servidores modernos suelen pasar minutos, en lugar de segundos, en el firmware antes de llegar al punto de iniciar un sistema operativo desde el disco. Esto se debe en gran parte a la mayor complejidad de los sistemas modernos. Una CPU ya no puede aparecer y comenzar a ejecutar instrucciones a toda velocidad; nos hemos acostumbrado a escalar la frecuencia de la CPU, estados inactivos que ahorran mucha energía y múltiples núcleos de CPU. De hecho, dentro de las CPU modernas hay una cantidad sorprendente de CPU más simples que ayudan a iniciar los núcleos principales de la CPU y brindan servicios de tiempo de ejecución, como la aceleración de la frecuencia cuando hace demasiado calor. En la mayoría de las arquitecturas de CPU, el código que se ejecuta en estos núcleos dentro de su CPU se proporciona como blobs binarios opacos.
En los sistemas OpenPOWER, cada instrucción ejecutada en cada núcleo dentro de la CPU es un software de código abierto. En máquinas con OpenBMC (como el sistema AC922 de IBM y los sistemas TALOS II y Blackbird de Raptor), esto también se extiende al código que se ejecuta en el controlador de administración de la placa base. Esto significa que podemos obtener una gran cantidad de información sobre lo que tarda tanto desde el momento en que conecta un cable de alimentación hasta el momento en que se muestra un indicador de inicio de sesión familiar.
Si eres parte de un equipo que trabaja en el kernel de Linux, probablemente arranques muchos kernels. Si forma parte de un equipo que trabaja con firmware, probablemente iniciará muchas imágenes de firmware diferentes, seguidas de un sistema operativo para asegurarse de que su firmware aún funcione. Si podemos reducir el tiempo de arranque del hardware, estos equipos pueden volverse más productivos y los usuarios finales pueden estar agradecidos cuando están configurando sistemas o reiniciando para instalar firmware o actualizaciones del sistema operativo.
Programación y desarrollo
- Blog de desarrolladores de Red Hat
- Hojas de trucos de programación
- Pruébelo gratis:Red Hat Learning Subscription
- eBook:Una introducción a la programación con Bash
- Hoja de referencia de secuencias de comandos de Bash Shell
- Libro electrónico:Modernización de Enterprise Java
A lo largo de los años, se han realizado muchas mejoras en el tiempo de arranque de las distribuciones de Linux. Los sistemas de inicio modernos manejan bien las cosas al mismo tiempo y bajo demanda. En un sistema moderno, una vez que el kernel comienza a ejecutarse, puede tomar muy pocos segundos llegar a un indicador de inicio de sesión. Este puñado de segundos no es el lugar para optimizar el tiempo de arranque; tenemos que ir antes:antes de llegar al sistema operativo.
En los sistemas OpenPOWER, el firmware carga un sistema operativo iniciando un kernel de Linux almacenado en el chip flash del firmware que ejecuta un programa de espacio de usuario llamado Petitboot para encontrar el disco que contiene el sistema operativo que el usuario desea iniciar y aplicarle kexec(). Esta reutilización de código aprovecha los esfuerzos que se han realizado para hacer que Linux arranque más rápido. Aun así, encontramos lugares en nuestra configuración de kernel y espacio de usuario donde podíamos mejorar y reducir fácilmente segundos de tiempo de arranque. Con estas optimizaciones, arrancar el entorno de Petitboot es un porcentaje de un solo dígito del tiempo de arranque, por lo que tuvimos que encontrar más mejoras en otros lugares.
Antes de que se inicie el entorno de Petitboot, existe un fragmento de firmware anterior llamado Skiboot, y antes de eso está Hostboot. Antes de Hostboot, se encuentra el motor de autoarranque, un núcleo separado en el chip que obtiene un solo núcleo de CPU y ejecuta instrucciones fuera del caché de nivel 3. Estos componentes son donde podemos avanzar más en la reducción del tiempo de arranque, ya que ocupan la gran mayoría. ¿Quizás algunos de estos componentes no están lo suficientemente optimizados o no hacen tanto en paralelo como deberían?
Otra vía de ataque es el tiempo de reinicio en lugar del tiempo de arranque. En un reinicio, realmente necesita reiniciar todo el hardware?
Como cualquier sistema moderno, las soluciones para mejorar el tiempo de arranque (y reinicio) han sido una mezcla de hacer más en paralelo, lidiar con el legado y (posiblemente) hacer trampa.
Stewart Smith presentará Arrancar más rápido en linux.conf.au, del 21 al 25 de enero en Christchurch, Nueva Zelanda.