Véngan esos 5… segundos para iniciar Linux!!

Hace unos días, un par de kernel hackers de Intel mostraron una prueba viviente de que es posible hacer que Linux se inicie en sólo 5 segundos. Y no hay trucos: En 5 segundos el sistema está listo para ser usado, eso quiere decir que el disco y cpu ya no se encuentran en uso y el escritorio está listo para comenzar a operar (Ver para creer). Bueno, también mostraron el ejemplo con un disco SSD para presentar el mejor caso, pero con un disco normal esto se puede obtener en 10 segundos.

En donde se agradecen estos logros? En equipos de escritorio que se apagan cuando no se usan, en dispositivos portátiles, en celulares, en laptops cuando suspend/hibernate no son una opción, etc.

He visto mucha confusión tanto en medios donde pulula gente informada como LWN, como en otros para todo tipo de público como FW. Espero que este artículo ayude a entender mejor de qué se trata este logro.

Estado actual

En un sistema Linux actual, el tiempo transcurrido desde que se inicia la carga hasta que aparece la ventana de login puede ser de unos 35 segundos a lo menos. Después de iniciar el escritorio pueden pasar unos 15 segundos adicionales (GNOME/KDE). Se pueden hacer cambios a la configuración original para mejorar el tiempo de inicio, pero tiene sus límites, es lo que publiqué en un artículo anterior. Aquí da casi lo mismo la distribución, ya que al modificar el inicio del sistema estamos tomando las mismas decisiones por las que pasa un desarrollador de una distribución, eliminando las diferencias entre una y otra, la única diferencia es que en algunas tendremos que hacer mas cambios que en otras.

En el caso de Windows, hay optimizaciones respecto a la carga de bibliotecas dinámicas y se reordena la ubicación física de los archivos entre otras cosas. Pero lo mas importante es que se permite que el usuario interactúe con el sistema aunque éste aún no se encuentre listo, atacando el problema desde el punto de vista de las percepciones. Esto se nota cuando ya se muestra el escritorio y el sistema es inusable porque el foco se pierde a cada rato y no se puede escribir, o el menú de inicio desaparece cada vez que quieres hacer click sobre él, o aparecen las ventanas de splash de cuanta basura haya instalada. Ya sabes, si crees que tu Windows se inicia rápido, el engaño ha sido exitoso.

En el caso de OSX, si se puede decir que es un sistema que inicia rápido de verdad. Cuando ves el escritorio ya está listo para ser usado. En este caso las optimizaciones aplicadas son muy astutas, y algunas de ellas han sido usadas en Linux también. Los interesados, revisen este artículo

Pero si mi CPU es de chorrocientos mil gigahertz asi que no importa

Una de las grandes falacias de la computación y de la cual todos los vendedores abusan es creer que una CPU rápida asegura que todo funcione más rápido. La realidad es que un computador es un sistema que funcionará tán lento como el más lento de sus componentes. En otras palabras, no siempre es más rapido ir en avión de una ciudad a otra, ya que se debe considerar la latencia, que es el tiempo en donde uno está esperando que algo suceda.

Lo mismo pasa en el sistema de inicio, hay tiempos en donde se está esperando que algo suceda y la CPU se encuentra totalmente inutilizada, algunos ejemplos:

• Lectura/escritura de archivos, o la búsqueda de un archivo en distintas ubicaciones posibles.
• Busqueda de datos en un disco. Los archivos que no se encuentran contiguos deben hacer que el cabezal se mueva, agregando más latencia.
• Timeouts. Ejecutar un comando y esperar a que se obtenga una respuesta, para tomar una acción después de que nadie responde
• Dispositivos lentos en inicializar, etc.

Focalizando el esfuerzo

En este experimento se plantearon un par de ideas que ayudaron a orientar los esfuerzos.

• Hacer que el sistema cargue «rápido» y no «más rápido». La diferencia es sutil en la forma, pero radicalmente diferente en el fondo. Hacer que cargue «más rápido» es lo que se ha intentado siempre: tomar lo que hay y eliminar algunas tareas para ahorrar tiempo, logrando que en total se ahorre la suma de esos tiempos pequeños. Se ha comprobado que no basta con paralelizar, porque eso trae otros inconvenientes. Hacer que el sistema cargue «rápido» en cambio, es plantear un tiempo objetivo y luego hacer que cada etapa no supere esa cuota y mezclar de forma que se disminuya la latencia. En terminos económicos básicos es como comparar el planteamiento entre gastar «$150.000 al mes» y «gastar menos al mes».
• Que no paguen justos por pecadores. Hay componentes del sistema que no son necesarios para toda la gente, o al menos no son necesarios para tener el sistema andando, por ejemplo CUPS para imprimir o en caso extremo sendmail para despachar correos locales. Todos estos componentes fueron eliminados, considerando que se pueden iniciar cuando sea necesario.

Ya ya ya ya.. pero ¿cuales fueron los cambios entonces?

Ok, aqui vamos. Los nominados son:

• Integrar los drivers que sean necesarios para bootear en el kernel, eliminando la necesidad de un initrd completo. Este cambio hace que este kernel sirva sólo para un grupo de equipos ya que elimina la carga dinámica de drivers antes de montar el sistema de archivos principal. Se han planteado alternativas de aplicar este cambio de una forma genérica para que los que puedan, carguen rápido el kernel.
• Inicialización asincrona de componentes del kernel. En vez de esperar a que un componente se termine de inicializar para continuar con el siguiente, se plantea iniciar varios en paralelo.
• Integrar readahead en el kernel. De esta forma se puede generar una lista de archivos a preleer cada vez que se inicia el sistema, sin tener que hacer un «profile» a mano como ahora.
• Aplicar readahead a nivel de bloques. Aprovechando el parche para readahead en el kernel, en vez de leer archivos completos, sólo se leeran los bloques que sean necesarios.
• Mejorar la lectura de los bloques ordenándolos. Aplicado al punto anterior, se pueden ordenar los bloques para que físicamente sean rápidos de leer desde disco.
• Optimizar la configuración de udev para que los archivos de /dev para iniciar el resto del sistema siempre estén disponibles, sin esperar la autodetección.
• Mejorar la inicialización de X. Hay tareas que se ejecutan pensando en que el sistema autodetecte cosas cada vez que se inicia, pero no es necesario cuando el hardware o los dispositivos de entrada nunca van a cambiar.
• En sistemas con autologin, iniciar directamente la sesión sin pasar con GDM, siempre está la opción de cambiar de usuario con el screensaver (+xlock)

Y para el resto del mundo, cuando?

El resto del mundo podrá ver estas mejoras en las siguientes versiones de la distribución. En Ubuntu se espera al menos para la versión de abril del próximo año (9.04 Jaunty Jackalope).

Se espera además que con el apoyo del resto de los proyectos involucrados, se logren mejoras que no se pudieron aplicar en este momento. Al menos en la misma conferencia así lo dijeron personajes de la talla de Keith Packard (X.org/Intel).