Optimizando el kernel de Linux para el escritorio (desktop) con xanmod

En ocasiones customizar y compilar el kernel de Linux/GNU puede ser una tarea que lleve mucho tiempo, no siempre invertir ese tiempo se justifica.

Eso se aplica si el hardware de tu PC es actual o si no querés sumergirte un poco en cómo el sistema funciona "bajo el capot".

Para quienes deseen exprimir su hardware al máximo y optimizar el comportamiento del sistema operativo para ciertos usos, por ejemplo optimizarlo para funcionar con aplicaciones "de escritorio" este post puede resultarles útil.

Hoy en día compilar el kernel del Linux es mucho más fácil de lo que acostumbraba ser. Xanmod o Liquorix ofrecen una serie de parches y optimizaciones que se aplican por sobre el kernel "vainilla" de Linux y que procuran optimizar el kernel para diferentes casos de uso.

Respecto de utilizar un kernel "de stock" provisto por nuestra distribución favorita, compilar el kernel nosotros mismos es una tarea que requiere invertir de cierto tiempo. Requiere al menos familiarizarse con el hardware en donde vamos a ejecutar ese kernel. Mi modesto consejo es configurá tu kernel si:

• Estás buscando optimizarlo para ciertos casos de uso.
• Si tu hardware es raro y requiere soporte que no estuviera ya presente en el kernel de tu distribución.
• Si por ejemplo un sistema embebido tiene relativamente pocos recursos y hay que reducir la "pisada" del sistema.

En mi caso más o menos recientemente solo necesité compilar el kernel cuando utilizo hardware antiguo. Por ejemplo si quisiéramos utilizar una unidad floppy o una interfaz ide un kernel estándar actual nos va a dejar a pie. Tengo una máquina que ya tiene cerca de doce años, es una pequeña netbook de las que el Gobierno de la Ciudad entregó a los alumnos de las escuelas primarias. Ya mis hijos no la utilizaban, porque quedó bastante rezagada para correr soft actual.

A mí me gusta por su diseño y su robustez. Puedo usarla a la intemperie, en cualquier clima. Y con Linux tiene una vida algo extendida, de otro modo ya habría ido a parar al callejón del olvido. Si bien el teclado no es cómodo, usé esa máquina para transcribir mi libro ("Piensa Abierto") de mis cuadernos manuscritos a archivos markdown, que fueron la base para su composición tipográfica. Demás está decir que navegar la web no es una experiencia llevadera en esa máquina, pero para escribir con visual studio o codear algunos script o aplicación simple resulta utilizable. Por eso me propuse hace unos días tratar de optimizarle algunos pocos ciclos de cpu a ver si podía reducir la latencia de ciertas aplicaciones. Pese a tener solo 1GB de ram, utilizo allí debian con enlightenment como gestor de escritorio, lo que hace al desktop elegante y liviano. El principal cuello de botella de la máquina es sin dudas su CPU, un antiguo Atom de Intel.

Xanmod y la optimización del kernel

Xanmod es una distribución de software, en este caso una distribución del kernel Linux que incluye varios parches y mejoras, algunas de las cuales no se incluyen en el kernel estándar. En general el fuerte de Linux/GNU desde su edad temprana ha sido correr en el servidor. Es por ello que con cierto grado de solución de compromiso, el kernel suele incluir una configuración que resulte estable para el servidor, pero no necesariamente está optimizada del todo para software de escritorio. Entre otros usos xanmod procura facilitar esos ajustes y "tweaks" para que uno pueda optimizar el kernel para el escritorio. Otra distribución alternativa es Liquorix . Estas distribuciones suelen incluir binarios ya compilados del kernel, empaquetados en paquetes .deb, por ejemplo utilizables en Debian o Ubuntu. Además existen paquetes para Arch, Fedora, etc. Un problema es que ya es raro que se incluyan binarios 32bits en estos builds, y el Atom de mi vieja netbook no es 64 bits. Compilar el kernel tenía entonces algo más de sentido. Además podría incluir algunos ajustes más para reducir la latencia, en particular me interesaba ajustar la "preferencia" del kernel (en inglés "preemption" para intentar reducir en algo la latencia del escritorio). Además podría seleccionar schedulers alternativos para controlar la Entrada/Salida de disco (este fierro viejo tiene hdd).

Compilando el kernel (usando el código fuente de xanmod) a la manera de Debian

Para comenzar, obviamente se requiere descargar el código fuente del kernel, en la distribución provista por xanmod. Como he descripto en una entrada en este blog hace ya varios años atrás voy a compilar el kernel a la Debian, eso quiere decir que los artefactos que resulten del build serán un puñado de archivos .deb (el kernel en sí, sus headers y al librería de C). De esa forma uno puede distribuir esa versión de su kernel "custom" de forma fácil. La manera en como se compila a la Debian ha cambiado hace un tiempo y hoy es incluso más fácil. Manos a la obra. Por supuesto no iba a compilar mi kernel en la vieja netbook, porque allí demoraría días, o quizá semanas. De forma que es mejor utilizar el hardware más potente que tengamos a mano. En mi caso, la PC de mi escritorio tiene un procesador AMD de 64 bits, de modo que es necesario hacer un cross-compiling para que los binarios resultantes sean de 32 bits. Pero eso no es más que pasarle un parámetro al compilador.
Si uno quiere empezar a jugar con la configuración y no invertir horas de prueba y error, lo más seguro es partir de una configuración conocida. En el directorio /boot tenemos la configuración del kernel que estamos utilizando y podemos partir de esa configuración para empezar a hacerle algunos cambios.

1) Instalar dependencias, si es la primera vez que vamos a compilar el kernel necesitaremos las herramientas de desarrollo:

$ sudop apt-get install build-essential bison flex

2) Para partir de una configuración "conocida", desde dentro del directorio de las fuentes de xanmod:

$ make localmodconfig

Con esto lo que haremos es crear el archivo de configuración del kernel (.config) a partir de la configuración del kernel actual y de los módulos que éste contiene.

3) Luego, copiar el directorio de xanmod a la máquina (más potente quizá) que utilizaremos para la compilación.

4) En este punto, previo a la compilación es cuando -si queremos- podemos hacer algunos ajustes. A mí me interesaba, como comenté antes, cambiar la preferencia del scheduler del kernel:

$ make menuconfig

Ese comando abrirá una interfaz ncurses para navegar las diferentes secciones de la configuración del kernel.

En la sección "Preemption Model", selecciné "Preemptible Kernel (Low-Latency Desktop)". Una nota sobre esto ¿De qué se trata el model de preferencia? Dicho en pocas palabras, define el modo en que el kernel elige entre las diferentes procesos o tareas que deben correrse en un sistema operativo multi-tasking (como todos los actuales). El modo seleccionado procura que las aplicaciones de escritorio puedan correr sin muchos contratiempos, aún cuando el sistema esté bajo una carga pesada, como suele ser el caso de mi netbook. Por otro lado quería experimentar también con el scheduler de Entrada/Salida, por ello agregué algunos schedulers que no suelen ser tan estándar:

Me interesó el scheduler BFQ. En este caso agregué el scheduler como módulo, de modo que si no lo quiero utilizar luego no ocupe más memoria en la imagen del kernel.

5) Finalmente (en una máquina más o menos "potente") hacer el build:

$ make ARCH=i386 -j 8 deb-pkg LOCALVERSION=-retux

Aquí con ARCH= indicamos la arquitectura target, que es i386 ya que se trata de un procesdor Atom de Intel. Con -j N podemos asignar un cierto número de núcleos de CPU disponibles para paralelizar la compilación.

6) Instalar en la máquina de destino, que usará este kernel instalar los .deb.

$ sudo dpkg -i *.deb

7) En la configuración del kernel, en los parámetros que grub le pasa en tiempo de boot, se puede seleccionar el scheduler BFQ y deshabilitar watchdog (que en una máquina de escritorio o laptop no es indispensable):

elevator=bfq nowatchdog

Con justicia, ustedes me preguntarán ¿Y los resultados? ¿Vale la pena el esfuerzo? Algunos mejoras en la netbook, en lo que hace a la latencia fueron perceptibles. No es el día y la noche, solo con esto no vamos a hacer de una pc de 13 o 14 años, pero en algo podemos extenderle la vida. Además puede ser el comienzo de otras experimentaciones para el que le interese.
Existe una analogía entre algo del "hacking" con la práctica de los radioficionados. Entre estos existe una práctica denominada transmisión QRP, que consiste en transmitir con la menor potencia en antena. De esa forma, lo que se procura es optimizar el rendimiento (de la línea de transmisión, de la antena, etc) para obtener el mejor resultado posible. De esa forma, un comunicado QRP tiene otra satisfacción diferente a la de poner 100W en antena.
Espacio para mejoras, siempre suele haber, por pequeño que este sea. Si puedo hacer algunos benchmarks prometo publicarlos próximamente.

Continuar »