El kernel "anteriormente conocido como Linux 3.20" acaba de debutar. Como ya sabréis a estas alturas, Linus Torvalds hizo una encuesta a ver que opinaba la gente de saltar a la rama 4.X y llamarlo 4.0, o seguir en la rama 3.X y llamarlo 3.20. Al final hizo lo que le salió de las narices, que casualmente coincidió con la opción que iba ganando, y aquí tenemos el flamante kernel 4.0, listo para descargar de kernel.org.

Uno podría pensar que un cambio de número de versión mayor significaría importantes novedades, o tal vez alguna rotura de la compatibilidad hacia atrás. Ni lo uno, ni lo otro. Como dice el propio Linus Torvalds en su mensaje de anuncio:

It definitely matches the "v4.0 is supposed to be a stable release", and very much not about new experimental features etc. I'm personally so much happier with time-based releases than the bad old days when we had feature-based releases.

Tal vez algún día acabe este sinsentido actual de que los números de versión importan un pito, pero hoy no es ese día.

¿Novedades de este kernel? Como decíamos, pocas. Se ha intentado justificar el cambio de versión como que el kernel por fin iba a poder parchearse en caliente con el mecanismo de kGraft/kpatch. Pero lo que se ha integrado es sólo un principio que en próximas versiones tendrá que completarse hasta que pueda considerarse terminado, por lo que es algo que difícilmente podría justificar el cambio a 4.0. En LWN.net destacan como novedades de esta versión el borrado de la llamada al sistema remap_file_pages(), mejoras en el soporte de sistemas de ficheros en memoria persistente, la nueva opción lazytime de mount y el Kernel Address Sanitizer (KASan). Los artículos sobre la merge window (1, 2, 3) tienen más información y KernelNewbies tendrá una lista más exhaustiva en el futuro (cuando esté terminada).

Tiempos de compilación

Hay importantes novedades en este apartado. Pero primero, por completitud, voy a poner los tiempos de los kernels de la rama 3.18.x desde el último reporte:

Compilando 3.18.7-amd64 desde 3.18.6-amd64 con -j4:

    $ time fakeroot make-kpkg -j4 --initrd --revision=3.18.7+1 --append-to-version=-amd64 kernel_image kernel_headers
    real    10m18.580s
    user    24m51.120s
    sys      1m38.232s

Compilando 3.18.8-amd64 desde 3.18.7-amd64 con -j4:

    $ time fakeroot make-kpkg -j4 --initrd --revision=3.18.8+1 --append-to-version=-amd64 kernel_image kernel_headers
    real    10m17.546s
    user    24m45.700s
    sys      1m33.312s

Compilando 3.18.9-amd64 desde 3.18.8-amd64 con -j4:

    $ time fakeroot make-kpkg -j4 --initrd --revision=3.18.9+1 --append-to-version=-amd64 kernel_image kernel_headers
    real    9m58.847s
    user    24m32.116s
    sys      1m34.192s

En el kernel 3.18.8 quité todo el soporte de I2O (que desaparecía completamente en la rama 3.19.x, no sé porqué los de Debian todavía lo estaban compilando si no se usaba desde hace muchísimos años) más algunos drivers serie que también sobraban. Eso significó una mínima ganancia. Pero lo importante estaba por venir.

Primero, me entero que construir los kernels de Debian con el paquete kernel-package está obsoleto y ya no se recomienda su uso. Resulta que ahora se construyen directamente con el objetivo deb-pkg que viene en los propios makefiles del kernel estándar. No sólo eso, es que encima make deb-pkg es más rápido que make-kpkg construyendo los paquetes .deb, a pesar de que hace un par de paquetes adicionales (linux-firmware-image-VERSION y linux-libc-dev). He compilado todos los kernels a partir del 3.19.1 así, y la verdad que la diferencia en tiempo se nota.

Segundo, he quitado la opción CONFIG_DEBUG_INFO, con lo que definitivamente no compilo con opciones de debug (anteriormente había reducido el tamaño de la información de debug pero no la había eliminado). Con ello no sólo ha disminuido el tamaño del directorio del kernel compilado de 2,2 GB a 1,2 GB, sino que también se ha reducido el tiempo compilación, gracias a no tener que compilar y generar la información de debug. La importante ganancia de velocidad la podéis notar abajo entre el primer kernel 3.19.1 (con información de debug aún) y el segundo 3.19.1 (sin información de debug). A partir de ese, todos los los kernels compilados no llevan info de debug.

Tercero, he quitado de la configuración del kernel las opciones de los módulos de seguridad (Linux Security Modules) SELinux, AppArmor y TOMOYO. Debian los compila por defecto en su versión del kernel, pero resulta que en realidad no se usan (hay que activarlos aparte e instalar paquetes adicionales si se desean usar). Así que ¡fuera! (al menos de momento). Este cambio es a partir de la compilación del kernel 3.19.2.

En conjunto los tres cambios han reducido un 30% el tiempo de compilación y generación de los paquetes, bajándolo de los 7 minutos:

Compilando 3.19.1-amd64 desde 3.18.9-amd64 con -j4:
    $ time make -j4 deb-pkg LOCALVERSION=-amd64 KDEB_PKGVERSION=1
    real    8m55.484s
    user    24m57.876s
    sys      1m15.820s

Compilando 3.19.1-amd64 desde 3.19.1-amd64 con -j4: (quitando CONFIG_DEBUG_INFO)

    $ time make -j4 deb-pkg LOCALVERSION=-amd64 KDEB_PKGVERSION=3.19.1-1
    real    7m26.924s
    user    21m11.156s
    sys      1m5.256s

Compilando 3.19.2-amd64 desde 3.19.1-amd64 con -j4: (quitando SELinux, AppArmor y TOMOYO)

    $ time make -j4 deb-pkg LOCALVERSION=-amd64 KDEB_PKGVERSION=3.19.2-1
    real    6m52.244s
    user    21m5.788s
    sys      1m5.428s

Compilando 3.19.3-amd64 desde 3.19.2-amd64 con -j4:

    $ time make -j4 deb-pkg LOCALVERSION=-amd64 KDEB_PKGVERSION=3.19.3-1
    real    6m53.320s
    user    20m56.484s
    sys      1m3.664s

Compilando 3.19.4-amd64 desde 3.19.3-amd64 con -j4:

    $ time make -j4 deb-pkg LOCALVERSION=-amd64 KDEB_PKGVERSION=3.19.4-1
    real    6m49.564s
    user    20m57.152s
    sys      1m4.132s

Aunque seguro que se puede bajar más, de momento me doy por satisfecho. Así que, a partir de ahora, se acabó esta sección (¡ohhhh...!). Salvo que haya cambios significativos en los tiempos de compilación que merezca la pena reseñar, no volveré a daros la tabarra con esto. Gracias por vuestra paciencia. :-)

¿Qué pasó con...?

En la entrada sobre la anterior versión 3.19 comentaba un par de bugs "nuevos" con el kernel, uno respecto a un dispositivo PCI (SMBus) para el que no se cargaba el driver por culpa de un problema de la BIOS (ACPI), y el otro unas bonitas excepciones del módulo DRM del driver propietario de NVIDIA.

El bug del módulo de NVIDIA se corrigió en cuanto salió una nueva versión más reciente del driver (la 346.47), no hizo falta ni siquiera esperar al nuevo kernel 3.19.

En cambio, respecto al bug de la ACPI la nueva versión no ha resuelto nada. Tampoco ha funcionado (la verdad es que era un tiro a ciegas) engañar a la BIOS cambiándole la versión de ACPI soportada a 2, inspirado en este comentario de Matthew Garrett. Tiene toda la pinta de ser uno más de los innumerables bugs que pueblan las BIOS, y salvo que al fabricante le dé por arreglarlo (dudoso), no hay mucho más que hacer¹.

:wq