· Soporte para GPUs Radeon RX 480 'Polaris'
Como resultado de la nueva política de drivers libres de AMD, esta versión incluye soporte en el driver amdgpu para las recientísimamente puestas en venta GPUs Polaris, la nueva generación de GPUs Radeon RX 480. El soporte está al mismo nivel que el resto de dispositivos del driver.
· Búsquedas de ruta de archivo paralelas en el mismo directorio
El caché de directorio (conocido como "dcache") es una de las partes más críticas del kernel, se trata de un caché de las rutas de los sistema de archivos, lo cual permite agilizar enormemente ciertas operaciones; por ejemplo, permite determinar si cierto archivo o directorio existe o no sin tener que leer datos del disco. Este cache usa un mutex para serializar las búsquedas de rutas en el mismo directorio.
Esta versión permite hacer búsquedas de rutas en el mismo directorio; el mutex serializador ha sido sustituido por un semáforo de lectura-escritura. Esta mejora no se notará en la vastísima mayoría de casos, porque las búsquedas en el caché de directorios son muy rápidas y es muy raro que se convierta en un punto de contención. Pero para algunas cargas específicas que utilizan la búsqueda de rutas muy intensivamente, verán una mejora del rendimiento porque a partir de ahora podrán hacerse en paralelo. La mayor parte de los sistemas de archivos han sido convertidos para utilizar esta característica.
· Nuevo gobernador de frecuencia experimental 'schedutils'
Esta versión incorpora un nuevo gobernador para el subsistema de escalado de frecuencias (cpufreq). Hay dos grandes diferencias entre este nuevo gobernador y los existentes. Primero, schedutils utiliza información proporcionada directamente por el planificador de procesos. Segundo, puede invocar los drivers cpufreq y cambiar la frecuencia más rápidamente.
Lo que esto significa es que el tiempo que tarda el gobernador en hacer cambios de frecuencia y la calidad de las decisiones tomadas mejora respecto a anteriores gobernadores. Nótese que este nuevo gobernador es muy simple, y está considerado como una base sobre la que fundar futuros cambios que mejoren la integración entre el planificador de procesos y la gestión de energía. Sin embargo, funciona y los resultados preliminares son prometedores. Este gobernador comparte algunos valores tuneables con los otros gobernadores.
· Soporte para construir histogramas de eventos en la interfaz de trazado ftrace
Los "Hist triggers" son una funcionalidad que se incorpora a ftrace, la infraestructura de trazado de Linux disponible desde 2.6.27 que está embebida en el kernel y disponible en /sys/kernel/debug/tracing. Esta versión añade el comando "hist" a ftrace, que permite construir "histogramas" de eventos, agregando el número de eventos en una tabla hash. Como ejemplo, vamos a suponer que un usuario quiere conseguir una lista de bytes leídos por cada proceso en el sistema. Se puede hacer con el comando "hist" de la siguiente manera:
# echo 'hist:key=common_pid.execname:val=count:sort=count.descending' > /sys/kernel/debug/tracing/events/syscalls/sys_enter_read/trigger
Lo que hace este extraño comando es escribir un comando al archivo trigger del evento sys_enter_read (el evento que corresponde a entrar en la llamada al sistema read(), es decir, intentar leer un archivo). Cuando se produzca el evento, se ejecutará un comando hist (hist:) que significa lo siguiente: cada vez que se dispare el evento, leer el PID (common_pid - puedes ver todos los campos posibles del evento en el archivo /sys/kernel/debug/tracing/events/syscalls/sys_enter_read/format) y convertirlo a nombre de proceso (sufijo .execname); esto será usado como clave (key=) en el histograma. El parámetro val=count hace que se lea también el campo count, que en el evento sys_enter_read se refiere al número de bytes leídos. Finalmente, tras el separador :, el parámetro sort=count.descending hace que el comando ordene el resultado por el campo count en orden descendiente. La salida resultante es esta:
Esta salida muestra qué procesos han leído archivos, cuantos bytes (count), y con cuanta frecuencia (hitcount, que no fue especificado en el comando pero se incluye por defecto).
Como se puede observar, esta pequeña herramienta permite hacer análisis muy útiles del sistema, y si bien ftrace no puede competir (ni lo pretende) con herramientas de trazado más potentes como LTTng, perf o SystemTap, puede ser una herramienta muy conveniente. Para más información, puedes ver la documentación sobre hist triggers, or leer este post recomendado de Brendan Egg: Hist Triggers in Linux 4.7. Para más documentation sobre ftrace, ver Documentation/trace/ftrace.txt
· Soporte para callchains en la utilidad perf trace
En esta versión, perf trace añade la habilidad de mostrar callchains cada vez que el proceso a trazar encuentra una llamada al sistema. Puedes probarlo con comandos como # perf trace --call dwarf ping 127.0.0.1. Puedes mostrar callchains para los eventos deseados: # perf trace --event sched:sched_switch/call-graph=fp/ -a sleep 1. El trazado de fallos de página (options -F/--pf) también lo soportan, por ejemplo, para trazar las llamadas a write() y los fallos de página con callchains mientras se inicia firefox, puede hacerse con # perf trace -e write --pf maj --max-stack 5 firefox. Una análisis de perf trace con callchains de todos los procesos de un sistema completo puede encontrarse aquí.
· Permitir que los programas BPF usen tracepoints
Los tracepoints son una suerte de printf()s dinámicos que los desarrolladores introducen en su código para que puedan ser utilizados más tarde para analizar el comportamiento del sistema. Los Tracepoints pueden ser utilizados por muchas utilidades: LTTng, perf, SystemTap, ftrace...pero no podían ser utilizados por programas BPF
Esta versión añade un nuevo tipo de programa BPF (BPF_PROG_TYPE_TRACEPOINT) que puede usarse para construir programas BPF que puedan recoger datos de los tracepoints y procesarlos dentro del programa BPF. Esta alternativa puede ser más rápida que acceder a los tracepoints mediante kprobes, puede hacer las interfaces de los programas de trazado más estable, y permite la construcción de herramientas de trazado más complejas.
· Soporte para el mecanismo 'Capsule' de EFI
Esta versión añade soporte para el mecanismo 'Capsule' de EFI, que permite pasar a EFI archivos de datos. EFI los valida y toma decisiones de acuerdo con sus contenidos. El uso más común para este mecanismo es incluir actualizaciones de firmware en una Capsule para que EFI haga la actualización en el próximo reinicio. Los usuarios pueden subir datos a Capsule escribiendo el firmware en el dispositivo /dev/efi_capsule_loader device.
· Soporte para controladores de USB virtuales en USB/IP
USB/IP permite compartir dispositivos USB sobre la red. Los dispositivos a compartir necesitan, sin emabrgo, ser reales. Esta versión soporte la capacidad de crear dispositivos USB virtuales sin necesidad de tener un dispositivo USB físico, tal sólo utilizando el subsistema de USB gadgets.
Esta característica tiene varios usos; el más obvio (el que ha motivado su desarrollo) es la mejora de la emulación de teléfonos en los entornos de desarrollo. Los teléfonos emulados pueden ahora conectarse a la máquina del desarrollador, o a una virtual, mediante USB/IP, y así utilizarlos como si fuera un teléfono físico. También es útil, por razones obvias, para pruebas y experimentos.
· El mecanismo de fencing de Android, sync_file, se considera estable
En esta versión, el código sync_file que estaba en el directorio de pruebas staging/, ha sido movido al kernel principal. Sync_file es una API desarrollada para Android para cubrir las deficiencias del mecanismo de fencing de Linux; para los interesados se pueden encontrar más detalles en la documentación oficial, Documentation/sync_file.txt.
· LoadPin, un módulo de seguridad para restringir el origen de los módulos del kernel
LoadPin es un módulo de seguridad que se asegura de que todos los archivos cargados por el kernel (módulos del kernel, firmware, imágenes kexec, políticas de seguridad, etc) tengan origen en un mismo sistema de archivos. Las expectativas son que ese sistema de archivos sea de sólo lectura, como por ejemplo un DVD o dm-verity (esta característica viene de ChromeOS, donde el sistema principal está verificado criptográficamente con dm-verity). Los sistemas con este tipo de sistemas de archivos podrán con este sistema forzar las restricciones citadas sin tener que recurrir a firmar criptográficamente los módulos (algo que Linux también soporta), lo cual es obviamente beneficioso para la seguridad
Estas son las novedades principales de este kernel. Como siempre, pueden encontrar la lista completa, y en inglés, en esta página.
