Ya se ha publicado la versión 5.1 de Linux. Entre los cambios que trae consigo está versión se encuentra: io_uring, una nueva interfaz de alto rendimiento para E/S asíncrona; también se incluyen mejoras a fanotify que proporcionan una manera escalable de vigilar los cambios en sistemas de archivos grandes; se añade un método para permitir la entrega segura de señales en presencia de reutilización de PIDs; la memoria persistente puede utilizarse como RAM; los niveles de compresión Zstd en Btrfs son configurables; también se añade un nuevo gobernador cpuidle que toma mejores decisiones de gestión energética que el gobernador menu; todas las arquitecturas de 32 bits han añadido llamadas al sistema con time_t de 64 bits para afrontar el problema y2038; es posible arrancar desde un dispositivo de device-mapper sin usar initramfs; y el parcheo en vivo ha añadido soporte para parches acumulativos. Además, hay muchas otras mejoras y pequeños parches. La lista completa de cambios, en inglés, se encuentra aquí.
1. E/S asíncrona de alto rendimiento con io_uring
Linux soporta E/S asíncrona desde hace mucho tiempo. Sin embargo, la interfaz tiene un amplio número de problemas. No soporta, por ejemplo, E/S con búfers, sólo E/S sin buffers (O_DIRECT), que sólo utiliza un subconjunto de un subconjunto de aplicaciones. Incluso en esos casos, la E/S no era siempre asíncrona ni rápida. Todos los intentos de mejorar la interfaz existente han fracasado.
Esta versión incluye una nueva interfaz, io_uring, que trae a Linux E/S asíncrona rápida y escalable, tanto con búfers como sin ellos, y soporta también E/S asíncrona con polling. Para más detalles, lea este documento (PDF) que explica las razones por las que se ha creado io_uring, su funcionamiento interno, y la interfaz de cara al usuario. Para detalles sobre el rendimiento, vea este email.
Adicionalmente, se ha creado una librería, liburing, para las aplicaciones que no necesitan o no quieran preocuparse de juguetear con los detalles de bajo nivel de la interfaz. Tiene ayudantes que permiten a las aplicaciones configurar una instancia io_uring y enviar/completar E/S in conocer los detalles más escabrosos de los anillos; continuará añadiendo ayudantes y más características con el tiempo.
Adicionalmente, se ha creado una librería, liburing, para las aplicaciones que no necesitan o no quieran preocuparse de juguetear con los detalles de bajo nivel de la interfaz. Tiene ayudantes que permiten a las aplicaciones configurar una instancia io_uring y enviar/completar E/S in conocer los detalles más escabrosos de los anillos; continuará añadiendo ayudantes y más características con el tiempo.
2. Mejoras en fanotify para una mejor monitorización del sistema de archivos
A diferencia de otros sistemas operativos, Linux no proporciona un sistema eficiente para vigilar los cambios que ocurren en un sistema de archivos grande. La única manera de monitorizar eventos de modificación a un directorio es inotify, que escala mal con grandes árboles de directorios. La interfaz fanotify, introducida en Linux 2.6.36, tenía la pretensión de sustituir inotify y solucionar sus deficiencias, e inicialmente dió algunos pasos en esa dirección, pero la funcionalidad requerida para sustituir a inotify por completo.
Esta versión (junto con los cambios añadidos en Linux 4.20) expanden inotify para proporcionar la funcionalidad "super block root watch", que es una manera escalable de observar los cambios en grandes sistemas de archivos. Para más detalles, lea el wiki del proyecto.
3. Entrega segura de señales en presencia de reutilización de PID
La llamada al sistema kill(2) opera con PIDs. Tras la salida y muerte de un proceso, su numero de PID puede ser reutilizado por otro proceso. Si un proceso envía una señal a un PID reutilizado, estará enviando la señal al PID equivocado. Este es un problema conocido con el diseño de Unix, y ha provocado numerosos problemas de seguridad.
Tras considerar varias opciones, Linux ha añadido la llamada al sistema pidfd_send_signal(2), que utiliza descriptores de archivo de /proc/
4. Utilización de memoria persistente como RAM
Linux soporta dispositivos de memoria persistente, pero normalmente son utilizados como dispositivos de almacenamiento. Algunas personas desean utilizar la memoria persistente como memoria volátil, están dispuestos a lidiar con las diferencias de rendimiento con la RAM, y quieren utilizar las APIs tradicionales de gestión de memoria en lugar de un asignador de memoria en espacio de usuario ubicado sobre el mmap() de un archivo DAX. Esta versión de Linux les permite hacer eso.
Linux soporta dispositivos de memoria persistente, pero normalmente son utilizados como dispositivos de almacenamiento. Algunas personas desean utilizar la memoria persistente como memoria volátil, están dispuestos a lidiar con las diferencias de rendimiento con la RAM, y quieren utilizar las APIs tradicionales de gestión de memoria en lugar de un asignador de memoria en espacio de usuario ubicado sobre el mmap() de un archivo DAX. Esta versión de Linux les permite hacer eso.
5. TEO, un gobernador alternativo a 'menu'
El subsistema cpuidle es la parte del kernel encargada de decidir qué estado de sueño profundo utilizar cuando la CPU no tiene nada que hacer (los estados de sueño más profundo ahorran más energía, pero cuesta más salir de ellos). Hay dos gobernadores cpuidle, "menu" y "ladder", cada uno con diferentes heurísticas. Sin embargo, se cree que el gobernador "menu" tiene una serie de deficiencias que han llevado a añadir una alternativa: TEO, Timer Events Oriented Governor, que parece ofrecer mejoras de rendimiento sin aumento del consumo de energía. Puede observarse el gobernador que está siendo utilizado en /sys/devices/system/cpu/cpuidle/current_governor_ro, y cambiar el gobernador por defecto en el arranque con el parámetro cpuidle.governor=teo.
6. Más preparación para el año 2038
Como parte del trabajo para prepararse para el problema del año 2038, esta versión incluye llamadas de sistema con time_t de 64 bits para todas las arquitecturas de 64 bits. Esto permite finalmente tener llamadas al sistema con 64-bit time_t en todas las arquitecturas.
Como parte del trabajo para prepararse para el problema del año 2038, esta versión incluye llamadas de sistema con time_t de 64 bits para todas las arquitecturas de 64 bits. Esto permite finalmente tener llamadas al sistema con 64-bit time_t en todas las arquitecturas.
7. Compresión Zstd configurable para Btrfs
Btrfs tiene soporte de compresión Zstd desde Linux 4.14, pero no permitía configurar el nivel de compresión utilizado. Esta versión añade soporte para configurar el nivel de compresión en Btrfs, como se hace con zlib, utilizando la opción de montaje -o compress=zstd:nivel. Para ver los niveles disponibles y su impacto en el rendimiento y en el ratio de compresión, vea este commit.
8. Arranque desde un dispositivo de device mapper sin initramfs
Para arrancar a un sistema de archivos ubicado en un dispositivo device mapper, se necesita un initramfs. Algunas personas, sin embargo, querrían o no pueden usar un initramfs. Esta versión permite utilizar targets DM en el proceso de arranque sin la necesidad de initramfs, con la ayuda de un complicado parámetro de arranque del kernel. Para más detalles vean la documentación.
9. parcheado en vivo: soporte para parches acumulativos
Puede haber dependencias entre los parches en vivo. Si diferentes parches necesitan hacer diferentes cambios a la misma función, es necesario definir el orden en el que los parches serán instalados. Y implementaciones de funciones en los parches en vivo más nuevos deberán realizarse encima de los viejos, algo que pronto se convierte en una pesadilla para mantener, especialmente si alguien quiere eliminar uno de los parches que está en medio de la pila. Una solución elegante que se incluye en esta versión es algo llamado "reemplazo atómico". Permite la creación de "parches acumulativos" que incluyen todos los cambios de los parches viejos y los reemplazan por completo en una sóla transición. Como resultado, los autores de parches en vivo pueden mantener las fuentes para un sólo parche acumulativo. Para más detalles, vea la documentación.
Btrfs tiene soporte de compresión Zstd desde Linux 4.14, pero no permitía configurar el nivel de compresión utilizado. Esta versión añade soporte para configurar el nivel de compresión en Btrfs, como se hace con zlib, utilizando la opción de montaje -o compress=zstd:nivel. Para ver los niveles disponibles y su impacto en el rendimiento y en el ratio de compresión, vea este commit.
8. Arranque desde un dispositivo de device mapper sin initramfs
Para arrancar a un sistema de archivos ubicado en un dispositivo device mapper, se necesita un initramfs. Algunas personas, sin embargo, querrían o no pueden usar un initramfs. Esta versión permite utilizar targets DM en el proceso de arranque sin la necesidad de initramfs, con la ayuda de un complicado parámetro de arranque del kernel. Para más detalles vean la documentación.
9. parcheado en vivo: soporte para parches acumulativos
Puede haber dependencias entre los parches en vivo. Si diferentes parches necesitan hacer diferentes cambios a la misma función, es necesario definir el orden en el que los parches serán instalados. Y implementaciones de funciones en los parches en vivo más nuevos deberán realizarse encima de los viejos, algo que pronto se convierte en una pesadilla para mantener, especialmente si alguien quiere eliminar uno de los parches que está en medio de la pila. Una solución elegante que se incluye en esta versión es algo llamado "reemplazo atómico". Permite la creación de "parches acumulativos" que incluyen todos los cambios de los parches viejos y los reemplazan por completo en una sóla transición. Como resultado, los autores de parches en vivo pueden mantener las fuentes para un sólo parche acumulativo. Para más detalles, vea la documentación.
Y eso es todo. Como siempre, pueden encontrar la lista completa de cambios, en inglés, en esta página.
