Audio digital en GNU/Linux: rt
Requisitos mínimos del sistema
Puede ser suficiente con un pentium 3 y 256 MB de RAM, pero con esto no podremos hacer gran cosa. Se recomienda como mínimo un pentium 4 con 1 GB de RAM. El disco duro debe ser lo más rápido posible, y es mejor usar dos. En cuanto a la tarjeta, si queremos tener 8 entradas no nos quedará más remedio que ir a un tarjeta (semi)profesional, pero si nos basta con dos entradas podemos usar una tarjeta tipo SoundBlaster. Incluso las tarjetas integradas en placa pueden dar una latencia aceptable, aunque la calidad del sonido deje bastante que desear.
Latencia
Latencia es el tiempo que tarda el ordenador en procesar nuestra señal. Es debida a que la CPU tiene que hacer muchas cosas "a la vez". En realidad, la CPU sólo es capaz de hacer una cosa a la vez: lo que ocurre es que va rotando entre todas las tareas que le encargamos. Podemos comparar a la CPU con el camarero de un bar. El camarero va sirviendo copas a todos los clientes (procesos); si el camarero fuera Superman, podría servir a supervelocidad, y la sensación sería que ha atendido a todo el mundo a la vez.
Por eso se suele usar una CPU lo más rápida posible. Se espera que la CPU sea capaz de atender a todos los procesos necesarios antes de que pase demasiado tiempo. Es una solución de "fuerza bruta".
El cerebro humano es capaz de percibir una latencia de 5 milisegundos. Por tanto, si logramos que los procesos de audio sean atendidos siempre antes de ese tiempo, tendremos un sistema de audio profesional.
Tiempo real (realtime, rt)
Es posible parchear el kernel Linux para que funcione en tiempo real. Siguiendo con el ejemplo, se trata de lograr que el camarero sea capaz de distinguir a los pringados de los VIP, y darle instrucciones para que atienda a los VIP antes de esos 5 milisegundos.
Si tenemos un camarero que funciona en tiempo real, aunque seamos unos pringados podemos acercarnos a la barra y pedirle una copa. Nos atenderá igual que antes. Pero si llega un VIP mientras nos está sirviendo, el camarero nos dejará colgados y atenderá primero al VIP. De este modo se puede eliminar la latencia incluso con una CPU vieja. Por supuesto, si queremos trabajar con un montón de pistas y efectos a la vez, necesitaremos una máquina bien potente.
Es importante darse cuenta de que el kernel rt no ofrece más rendimiento que el kernel normal. De hecho, el rendimiento del kernel rt es inferior (ya que el camarero ha dejado caer nuestra copa y tiene que volver a servirla después). Lo que sí ofrece es la capacidad de atender al cliente VIP antes de un tiempo X, que es lo que nos interesa de verdad.
También hay que tener en cuenta que sólo puede haber un VIP por cada camarero. Es decir, en un sistema con un solo procesador, sólo puede haber un proceso que funcione en tiempo real. De ahí la necesidad de configurar bien nuestro sistema.
Desde hace años se vienen incorporando porciones del parche rt al kernel Linux normal. Como resultado, la latencia del kernel normal es mucho mejor que antes y es posible usarlo en la mayoría de los casos. No necesitamos el kernel rt para reproducir audio, ni para editar/mezclar/masterizar nuestras grabaciones. Incluso es posible que podamos conectar un teclado a nuestro sistema y tocar con él sin que se note la latencia. Sin embargo, si estamos grabando en estudio/directo, probablemente querremos usar el kernel rt.
Por otra parte, el kernel rt es capaz de hacer funcionar todo nuestro sistema con absoluta normalidad y fiabilidad: las mayores Bolsas del mundo (New York, Chicago, London, Berlin... etc), han migrado al kernel rt. Nada impide que usemos el kernel rt en todo momento, aunque el rendimiento sea menor que con el kernel normal.
Distros multimedia.
La manera más sencilla de lograr un sistema capaz de funcionar en tiempo real es usar una distro multimedia. Estas distros suelen incluir un kernel rt.
Planet CCRMA(pronunciado Karma) está basada en Fedora o CentOS. Es un producto de la Universidad de Stanford y es una de las distros multimedia punteras.
Musix es una distro argentina basada en Knoppix y Debian (stable). La alberga la FSF, está considerada 100% libre y tiene abundante documentación en castellano. Al usar Debian estable, es posible que el software sea un poco antiguo comparado con otras distros, pero a cambio funcionará sin problemas. Tiene manual de instalación, manual de usuario y Wiki.
64Studioes compatible con Debian y Ubuntu. Está enfocada a 64 bits, pero tiene una versión a 32 bit. Hay quien se queja de que la versión estable no se ha actualizado desde Debian Etch. De ser así, el software que incluye es más antiguo que el de Musix.
Ubuntustudioes parte de la propia Ubuntu. Hay que tener en cuenta que no siempre ha incluido un kernel rt. Como no la uso, no sé si esto sigue siendo así o no . Por otra parte, ya hemos visto que el kernel normal también tiene poca latencia.
Distros normales.
Cualquier distro puede funcionar en tiempo real a condición de usar el kernel rt. Si compilamos nuestro propio kernel, podemos configurarlo para aprovechar al máximo las capacidades de nuestra CPU. La ganancia de rendimiento puede ser importante con respecto a los kernel "genéricos" que suelen traer las distros. Para que el parche rt se aplique correctamente, hay que usar el kernel oficial disponible en kernel.org.
Configurar el kernel para funcionar en tiempo real puede ser tan sencillo como sota-caballo-rey. Basta con limitarse a activar las pocas opciones necesarias. Pero si intentamos optimizar más, la cosa se complica, y la ganancia de rendimiento es despreciable, a no ser que estemos en un caso especial.
A lo largo de esta guía se explica con detalle como configurar y compilar el kernel, así como lo necesario para afinar una distro normal y convertirla en "distro multimedia"
Esta guía supone que ya tienes experiencia con GNU/Linux y que sabes usar la linea de comandos. Aunque se indican todos los comandos necesarios, si eres un novato absoluto, es mejor que uses alguna de las distros multimedia enumeradas en el apartado anterior. De ese modo podrás concentrarte en hacer música.
¿32 o 64 bit?
Personalmente prefiero ir a 64 bit si la máquina es capaz de ello. En caso de querer usar plugins VST, suele recomendarse ir a 32 bit ya que los VSTs suelen ir a 32 bit. Para usar los VSTs hay que usar wine (un programa capaz de ejecutar software para Windows).
El kernel tiene una opción (CONFIG_IA32_EMULATION, dentro de Executable file formats / Emulations), que permite ejecutar código de 32 bits en un sistema a 64 bit. Por tanto debería ser posible ejecutar plugins VST de 32 bit en un sistema a 64 bit. El caso es que hay plugins libres (y además nativos) de buena calidad, por tanto nunca me he planteado usar VSTs.
Disco duro.
El disco duro debe ser lo más rápido posible, a 7200 rpm o más. Hoy día los discos más rápidos son los SSD, que no tienen partes móviles. El problema de usar un solo disco es que antes o después el sistema necesitará leer algo, y mientras busca y lee ese algo, no puede escribir nuestros datos. La solución tradicional es usar dos discos, dejando el segundo en exclusiva para escribir los datos de audio/multimedia.
Si estamos usando discos duros IDE, los discos deben estar configurados como maestros y por cada cable IDE debe haber un solo disco. Nada de poner dos discos en el mismo cable como maestro y esclavo, si lo hacemos nos cargamos el rendimiento.
Si tienes discos IDE capaces de usar el modo udma3 o superior, asegúrate de usar cables de 80 hilos. De lo contrario, desperdiciarás la mitad de la velocidad del disco, ya que estos cables están limitados a una transferencia máxima de unos 30-35 MB/s. Los discos duros modernos suelen tener tasas de transferencia de 70 MB/s o más.
hdparm
En los viejos tiempos, se recomendaba afinar el funcionamiento del disco duro usando hdparm. hdparm permite ver y ajustar los parámetros que controlan el funcionamiento del disco duro. Prácticamente se daba por seguro que los parámetros por defecto del sistema no sacaban todo el provecho posible de nuestro disco duro. Sin embargo, esto ya es historia.
Hoy en día, el sistema es capaz de sacar automáticamente el rendimiento máximo que ofrezca nuestro disco duro. De lo único que tenemos que preocuparnos es de usar cables de 80 hilos en caso de que el disco sea capaz de usar los modos udma3 y superiores. La utilidad de hdparm es ahora principlamente la de permitirnos ver de qué es capaz nuestro disco duro y qué está usando:
root@jhonki:/home/jon# hdparm -i /dev/sdb
/dev/sdb:
Model=ST3500630A, FwRev=3.AAF, SerialNo=9QG93J0X
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
BuffType=unknown, BuffSize=16384kB, MaxMultSect=16, MultSect=16
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=976773168
IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5
AdvancedPM=no WriteCache=enabled
Drive conforms to: Unspecified: ATA/ATAPI-1,2,3,4,5,6,7
* signifies the current active mode
Como podemos ver, el modo udma5, que es el más rápido que puede usar nuestro disco, está marcado con un asterisco. Por tanto ya lo estamos usando. Si estamos usando un modo *DMA, el resto de parámetros que controla hdparm son irrelevantes.
Ahora podemos comprobar la tasa de transferencia:
root@jhonki:/home/jon# hdparm -t /dev/sdb
/dev/sdb:
Timing buffered disk reads: 230 MB in 3.00 seconds = 76.60 MB/sec
Así que somos capaces de mover 76 MB por segundo hacia/desde el disco duro (un IDE Seagate Barracuda de 500GB a 7200 rpm)
En cambio, el mismo disco, con un cable de 40 hilos, queda limitado a una transferencia de 30-35 MB/s. Tanto con el módulo PATA como con el viejo módulo IDE, el sistema usa los mejores ajustes posibles: udma2 (PATA, 30 MB/s) y udma3 (IDE, 35 MB/s).
Usando SATA/PATA, hdparm no es capaz de cambiar el modo en que funciona el disco, porque libata (la librería que es la base de SATA y PATA), no hace caso de hdparm. Usando el viejo módulo IDE, hdparm sí que puede poner el disco en modo udma5, pero la transferencia sigue igual (35 MB/s en vez de 76), porque el cuello de botella está en el cable de 40 hilos.
Resumiendo: hoy en día, la utilidad de hdparm consiste en poder ver cuál es el modo udma más rápido que puede usar nuestro disco, y comprobar que efectivamente es el que se está usando. Si el disco es capaz de udma3 o superior, debemos usar un cable de 80 hilos; en caso contrario, podemos usar un cable viejo de 40 hilos. Si hacemos esto, el sistema podrá aprovechar automáticamente toda la velocidad de nuestro disco duro, y nosotros nos ahorraremos el tener que cacharrear con las opciones de hdparm.
Sistema de archivos
Lo que más nos interesa es que el sistema de archivos tenga una velocidad de escritura secuencial (es decir, la velocidad con la que escribe un único archivo grande) lo mayor posible. También nos interesa que nuestros datos estén seguros y que los chequeos no duren una eternidad.
Según esta comparativa, el viejo sistema de archivos ext2 es más rápido que sus sucesores ext3 y ext4. Teniendo en cuenta que ext2 no usa journal, es lógico que sea más rápido. Sin embargo, el journal incrementa la seguridad de nuestros datos. No es que ext2 vaya a perder datos, pero nunca está de más precaverse. Además, el uso de un sistema con journal tiene la ventaja de chequear el sistema de archivos muchísimo más rápido.
Por otra parte, ext4 es casi tan rápido como ext2 escribiendo, es más rápido leyendo y su rendimiento puede ser incrementado alredor de un 30% añadiendo las opciones noatime,data=writeback,barrier=0,nobh en el archivo /etc/fstab.
ext4 también es más rápido escribiendo que XFS y ReiserFS. Por desgracia, desde el kernel 2.6.31 la velocidad de lectura de ext4 es la mitad de lo que era antes, pero la velocidad de escritura permanece casi igual. Por tanto la elección parece bastante clara: nos conviene usar ext4, a menos que realmente necesitemos exprimir al máximo la capacidad de escritura, en cuyo caso podemos usar ext2 (y resignarnos a soportar sus chequeos, que duran una eternidad en comparación con los de ext4).
A continuación vemos las líneas del archivo /etc/fstab referidas a la partición raíz y la partición /home tras la instalación:
# / was on /dev/sda1 during installation
UUID=40c68279-3006-4416-b222-e100b35174f1 / ext4 errors=remount-ro 0 1
# /home was on /dev/sdb1 during installation
UUID=88234505-6fbb-4495-bcd1-52901827fe22 /home ext4 defaults 0 2
Podemos mejorar bastante el rendimiento de la partición que nos interese (en este caso /home) modificando la línea correspondiente para añadir las opciones noatime y data=writeback:
# /home was on /dev/sdb1 during installation
UUID=88234505-6fbb-4495-bcd1-52901827fe22 /home ext4 defaults,noatime,data=writeback 0 2
El rendimiento puede mejorarse aún más añadiendo también las opciones barrier=0 y nobh; sin embargo la ganacia de rendimiento que ofrecen estas opciones es pequeña, y en algún caso extremo podrían provocar una pérdida de datos, por lo que no se recomiendan.
Una última mejora se puede hacer con:
root@jhonki:/home/jon# tune2fs -O dir_index /dev/sdb1
dir_index construye un b-tree en el sistema de archivos, acelerando las búsquedas.
Descargar el kernel y aplicar el parche rt
En esta guía se usa Debian y se describe cómo compilar un kernel "a la Debian", usando fakeroot y make-kpkg. El mecanismo está disponible en todas las distros derivadas de Debian (Ubuntu, etc).
Lo primero es descargarse el parche rt. Estos parches están diponibles en http://www.kernel.org/pub/linux/kernel/projects/rt/.
Hay toda una colección de parches rt. Normalmente escogeremos el último disponible, en este caso http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.33.6-rt26.bz2 , a menos que tengamos interés en una versión en particular. Esta descarga suele pesar menos de 1 MB.
Acto seguido nos descargamos el kernel correspondiente (unos 60 MB) desde http://www.kernel.org/pub/linux/kernel/v2.6/. La colección es incluso mayor, están todos los kernels desde el primero al último. Si nos hemos bajado el parche 2.6.33.6, tendremos que descargar el kernel linux-2.6.33.6.tar.bz2
Por convención, el kernel se compila dentro de la carpeta /usr/src. Esta carpeta es propiedad del usuario root (el administrador del sistema) y del grupo root. Sin embargo Debian recomienda compilar el kernel como usuario normal. De modo que vamos a cambiar los permisos para que /usr/src sea propiedad del grupo src y pueda escribir en ella. Luego añadiremos a nuestro usuario (jon) al grupo src. Por último instalaremos los paquetes necesarios para configurar y compilar el kernel. Todo esto hay que hacerlo como root, claro.
jon@jhonki:~$ su
(contraseña de root)
root@jhonki:/home/jon# chgrp src /usr/src
root@jhonki:/home/jon# chmod g+w /usr/src
root@jhonki:/home/jon# adduser jon src
root@jhonki:/home/jon# aptitude install fakeroot libncurses5-dev kernel-package
root@jhonki:/home/jon# exit
Ahora (como jon) informamos al sistema de que somos miembros del grupo src y movemos las fuentes del kernel y el parche a la carpeta /usr/src
jon@jhonki:~$ newgrp srcjon@jhonki:~$ mv Downloads/linux-2.6.33.6.tar.bz2 /usr/src/
jon@jhonki:~$ mv Downloads/patch-2.6.33.6-rt26.bz2 /usr/src/
Nos cambiamos a la carpeta /usr/src, descomprimimos las fuentes, descomprimimos el parche, creamos un enlace simbólico "linux" que apunta a la carpeta con las fuentes descomprimidas (otra convención), entramos en la carpeta, y aplicamos el parche
jon@jhonki:~$ cd /usr/src
jon@jhonki:/usr/src$ tar jxvf linux-2.6.33.6.tar.bz2
jon@jhonki:/usr/src$ bunzip2 -d patch-2.6.33.6-rt26.bz2
jon@jhonki:/usr/src$ ln -s linux-2.6.33.6 linux
jon@jhonki:/usr/src$ cd linux
jon@jhonki:/usr/src/linux$ patch -p1 < ../patch-2.6.33.6-rt26
Configurar el kernel para realtime
Desde el kernel 2.6.32 tenemos un nuevo método de configuración, "make localmodconfig". Este método es capaz de ver qué módulos estamos usando y se encarga de activar "solo" las opciones correspondientes. Esto evita a los novatos los problemas de aprender el significado de cada opción del kernel y acorta mucho la compilación.
Sin embargo, antes de hacer "make localmodconfig" conviene asegurarse de que tenemos todo nuestro hardware conectado y encendido (por ejemplo la impresora). De este modo nuestro lápiz USB o reproductor de MP3 funcionará con nuestro nuevo kernel; en caso contrario, podemos encontrarnos que el nuevo kernel no tiene el módulo necesario.
El proceso es bien sencillo: una vez parcheadas las fuentes del kernel, hacemos:
jon@jhonki:/usr/src/linux$ make localmodconfig
La configuración se hace automáticamente, pero la shell nos hará una serie de preguntas, acerca de opciones nuevas o de opciones con múltiples valores. El problema es que en algunos caso no se nos hará la pregunta deseada; por ejemplo, no se nos preguntará si queremos optimizar el kernel según nuestro procesador. Habrá otros casos similares, por tanto lo que se recomienda es pulsar ENTER a cada pregunta. Eso acepta la configuración por defecto que propone "make localmodconfig". Acto seguido podemos retocarla con:
jon@jhonki:/usr/src/linux$ make menuconfig
"make menuconfig nos presenta un interfaz tipo "cajero automático" por el que podemos desplazarnos usando las teclas de flecha/tabulador, entramos en las opciones pulsando ENTER y con pulsaciones sucesivas en la barra espaciadora escogemos si queremos compilar como módulo (veremos una "m" en la opción), compilar dentro del kernel (veremos un asterisco) o no compilar (la opción queda en blanco).
Como mínimo debemos activar el soporte para realtime, en el apartado " Processor type and features " ---> Preemption Mode (Complete Preemption (Real-Time))
Sin embargo, merece la pena configurar unas pocas cosas más, que iremos viendo por apartados:
-*- Enable the block layer ---> (seleccionar y pulsar ENTER)
IO Schedulers --->
<*> Deadline I/O scheduler
Default I/O scheduler (Deadline) ---> (seleccionar, entrar y escoger deadline)
Ahora usamos las teclas de flecha (<-- , -->) o el tabulador para seleccionar "EXIT" en la base de la pantalla, eso nos devuelve al nivel inmediato superior, necesitamos repetirlo dos veces para volver al primer nivel y seguir con la configuración.
Processor type and features --->
[*] Tickless System (Dynamic Ticks)
[*] High Resolution Timer Support
[*] Symmetric multi-processing support (activar sólo si tienes más de una CPU/core)
Processor family (Opteron/Athlon64/Hammer/K8) ---> (escoge tu familia de CPU)
(4) Maximum number of CPUs (ajústalo a tu número de CPUs/cores para ahorrar RAM)
[*] SMT (Hyperthreading) scheduler support (activar sólo si tienes una CPU con HT)
[*] Multi-core scheduler support (activar sólo si tienes más de una CPU/core)
Preemption Mode (Complete Preemption (Real-Time)) ---> (entrar y seleccionar)
[*] Numa Memory Allocation and Scheduler Support (solo en i7 o superior, opteron)
[*] MTRR (Memory Type Range Register) support
Timer frequency (1000 HZ) ---> (entrar y seleccionar)
Si la máquina funciona a 32 bit, en este apartado encontraremos también una opción "HPET Timer" y otra "HPET emulate rtc" que conviene activar en caso de que nuestra placa madre soporte HPET. Si la placa madre está fabricada después de 2005, probablemente tiene HPET. Se trata de un reloj hardware que sustituye a los antiguos PIT y RTC. Es más preciso y se recomienda para multimedia. Puede estar desactivado en la BIOS, así que conviene entrar en la BIOS y asegurarse que lo tenemos activado. El reloj usado por el sistema no afecta al rendimiento del audio, porque la tarjeta de audio tiene su propio reloj. Pero sí afecta al MIDI. El sistema se encarga de seleccionar automáticamente el reloj de mejor rendimiento entre los disponibles.
NOTA: En máquinas a 64 bit no aparecen estas opciones: se configuran por defecto. Más abajo veremos que el el apartado "Device drivers--->Character devices" hay otro par de opciones sobre HPET, que activaremos siempre en caso de que la máquina vaya a 64 bit. Si va a 32 bit, sólo debemos activarlas si la placa madre tiene HPET.
Una vez terminado este apartado, seleccionamos EXIT y pulsamos ENTER.
Power management and ACPI options --->
[*] Power Management support
[*] ACPI (Advanced Configuration and Power Interface) Support --->
Aparte de estas dos opciones, se solía recomendar desactivar todo lo que está en el apartado "Power Management and ACPI options" , ya que alguna de estas opciones pueden inducir latencia. Por supuesto, si desactivamos todo, el ahorro de energía deja de funcionar, y también dejan de funcionar cosas como el botón de apagado, el control del ventilador, etc. En general, incluso con todas estas opciones activadas, la latencia es aceptable. Pero si quieres reducir la latencia al mínimo, es mejor desactivarlas.
Dentro del submenú "CPU Frequency Scaling" (suponiendo que activemos la opción) deberemos escoger al menos uno de los "governor" y usarlo como "governor" por defecto. Si nos preocupa la latencia, probablemente es el "performance governor" el que nos interesa. Los demás se pueden dejar como módulos.
"make localmodconfig" deja activadas varias opciones "debug" que no queremos en un kernel "de producción" ya que esas opciones reducen el rendimiento y/o incrementan la latencia. Para eliminarlas, vamos al apartado "Kernel hacking" y desactivamos todo.
Con eso terminamos la configuración. Seleccionamos EXIT en el fondo de la ventana y pulsamos ENTER hasta que en la ventana se nos pregunte:
Do you wish to save your new kernel configuration?
Seleccionamos YES y pulsamos ENTER. Eso nos devuelve a la línea de comandos. Podemos pasar a compilar, usamos el siguiente comando:
jon@jhonki:/usr/src/linux$ fakeroot make-kpkg --append-to-version=-identificador --revision=version --initrd kernel-image
"identificador" puede ser cualquier cadena de texto adecuada, pero hay que tener cuidado con guiones bajos y puntos; usar guiones normales no da problemas. Por ejemplo, un identificador válido podría ser "-k8", indicando un kernel para procesador k8 (athlon)
"revision" sirve sobre todo para evitar que se nos añada por defecto un string "Custom-bla-bla-bla", lo más normal es añadir un número (tipo "01", "02", etc, para indicar una recompilación del kernel con sólo algún pequeño cambio). Por desgracia apt no se entera del número de revisión, así que personalmente lo pongo en el "identificador" (p.ej: -k8-01, además de en la "revisión" (para evitar que aparezca el "custom-bla-bla-bla). de este modo resulta más fácil distinguir una versión de otra.
--initrd indica que queremos que el kernel cree un archivo (que actualmente es un initramfs) que se usa durante el arranque. Este initramfs, entre otras cosas, contiene los módulos necesarios para que nuestro sistema pueda arrancar. Si hemos compilado dentro del kernel todo lo necesario para que el sistema arranque, no es necesario usar este archivo. Sin embargo la tendencia es usarlo, y de hecho, al instalar el paquete deb que se creará, initramfs-tools automáticamente creará un initramfs, por tanto lo más sencillo es seguir la moda y usarlo.
Una vez terminada la compilación, aparecerá un paquete .deb en el directorio superior, es decir, en /usr/src. Este paquete se llamará según este patrón:
"linux-image-kernelversion-rtversion-identificador_revision_arquitectura.deb".
Para instalarlo debemos ser root, así que haremos lo siguiente:
jon@jhonki:/usr/src/linux$ cd ..
jon@jhonki:/usr/src$ su
[password de root]
root@jhonki:/usr/src# ls
linux linux-image-2.6.33.7-rt29-k8-01_01_amd64.deb
linux-2.6.33.7 patch-2.6.33.7-rt29
linux-2.6.33.7.tar.bz2
root@jhonki:/usr/src# dpkg -i linux-image-2.6.33.7-rt29-k8-01_01_amd64.deb
Eso instalará nuestro nuevo kernel y hará todos los ajustes necesarios, de modo que al reiniciar el sistema, grub nos ofrecerá la opción de arrancar con el kernel antiguo o con el nuevo.
Configuración minima, módulos, initramfs.
"make localmodconfig" desactiva gran número de módulos innecesarios, pero no todos. Por ejemplo, dejará activados todos los módulos para tarjetas de sonido. Hay quien prefiere compilar un kernel mínimo con los módulos justos para que funcione su hardware o incluso menos: sólo lo justo para que funcione el audio/midi. De este modo se extrae el máximo rendimiento al hardware que tengamos (y de paso se reduce el tiempo necesario para compilar). Por desgracia, configurar un kernel mínimo que funcione no es grano de anís.
Si tienes un portátil que se empeña en compartir la IRQ de la tarjeta de sonido, el kernel mínimo puede ser la única solución. Más sobre esto luego.
Dejando aparte los problemas de IRQs, si tu máquina tiene 1GB de RAM o más, y nunca has compilado un kernel, olvídate de configuraciones mínimas. Lo explicado en el apartado anterior es suficiente para tí. Si estás en un caso especial, o si te gusta trastear, puedes terminar de leer este apartado.
Aquí tienes una configuración mínima para el kernel 2.6.33.6-rt26, que puede servirte como punto de partida. Tal como está, sirve para una placa madre nvidia nforce4, procesador athlon, soporta módulos e initramfs, SATA, PATA, ext4, tarjeta gráfica radeon, tarjeta de audio M-audio Delta 1010LT, cd/dvd, teclado, ratón, audio y MIDI. Tienes que copiarla dentro de la carpeta con las fuentes del kernel, con el nombre ".config" y acto seguido hacer "make oldconfig".
En esta configuración mínima, todo lo que no es estrictamente necesario para trabajar con audio (pci) y midi está desactivado, incluso USB, firewire y la red. Si tu hardware es distinto, tendrás que activar los módulos correspondientes a tu placa, procesador, tarjeta gráfica y de sonido. Si tienes una tarjeta de sonido USB o firewire, tendrás que activar el soporte necesario. Para hacer los cambios que necesites, después de hacer "make oldconfig" tendrás que hacer "make menuconfig", según lo explicado en el apartado anterior.
Usando un kernel mínimo, se reduce un poco el consumo de RAM. Podemos verlo con el comando "dmesg | grep Memory". Por ejemplo, con el kernel normal 2.6.33.6 (no-rt):
jon@jhonki:~$ dmesg | grep Memory
[ 0.000000] Memory: 1016784k/1047424k available (3060k kernel code, 452k absent, 30188k reserved, 1885k data, 584k init)
Esto nos dice que después de cargar el kernel, nos quedan 1016784 KB de RAM libres. Por tanto, el kernel necesita unos 30 MB. Veamos ahora lo que necesita el mismo kernel, en versión rt, con la configuración mínima:
jon@jhonki:~$ dmesg | grep Memory
[ 0.000000] Memory: 1024496k/1047424k available (1954k kernel code, 388k absent, 21908k reserved, 918k data, 272k init)
El kernel mínimo ocupa unos 22 MB. Estamos ahorrando 8 MB de RAM. No es un gran ahorro. Siempre será mejor añadir más RAM que andar compilando un kernel mínimo. En cuanto a la carga del sistema, la diferencia entre el kernel normal y el mínimo también es despreciable. A menos que estemos en un caso especial, no merece la pena.
Siguiendo en esta onda, antiguamente se hablaba de compilar sólo lo necesario, no como módulo, sino dentro del kernel. Esto permite eliminar también el soporte para módulos y el soporte para initramfs/initrd. Por tanto, teóricamente tendríamos un kernel realmente mínimo.
Pues bien: ni se te ocurra hacerlo. En la práctica es contraproducente. Si activamos las mismas opciones, en un caso usando módulos y en el otro no, el kernel sin módulos consume más RAM. Si compilas el soporte para el ratón PS2 dentro del kernel, también se mete dentro del kernel el soporte para los touchpad synaptics, los alps, ratones "raros", etc, y por tanto se cargan en la memoria, sean necesarios o no. En cambio, compilando el ratón PS2 como módulo, el soporte para synaptics, etc, sólo se carga en la RAM si realmente es necesario. El del ratón PS2 no és el único ejemplo: hay otros muchos.
Si compilamos "a la Debian" tal como se explica en esta guía (lo que tiene la ventaja de crear un paquete .deb que podemos administrar con apt), los scripts de instalación se van a empeñar en generar un archivo initramfs. Resultado: el nuevo kernel no arranca... porque hemos quitado el soporte para initramfs :P . Podemos solucionarlo, pero la pequeña ganancia de velocidad en el arranque no merece la pena.
Con el kernel 2.6.33.6 he observado otros efectos colaterales desagradables: al compilarlo todo dentro del kernel, el sistema se queja de que no puede cargar el firmware de mi tarjeta radeon. Y no se ve nada acerca del nuevo KMS (kernel mode setting). Pero usando módulos, el firmware aparece donde debe estar, no hay ninguna queja, y el KMS funciona.
