Ya se ha anunciado la versión 4.10 de Linux. Esta versión añade soporte para GPUs virtualizadas, una nueva herramienta 'perf 2c2' para el análisis de contención de cachelines en sistemas NUMA, un nuevo comando 'perf sched timehist' para obtener un historial detallado de la asignación de tareas, una mejora en la gestión de escritura a disco que debería proporcionar mejor interactividad bajo escritura intensa, un nuevo método de polling híbrido para dispositivos de bloque que utiliza menos CPU que el polling puro, soporte para dispositivos ARM como el Nexus 5 y 6 o Allwinner A64, una característica que permite asignar programas eBPF a cgroups, un caché experimental de RAID5 en el subsistema MD y soporte para la tecnología de Intel Cache Allocation Technology. También se han incluido drivers nuevos y muchas otras mejoras y pequeños cambios. La lista completa de cambios, en inglés, puede encontrarse aquí, como siempre.
· Soporte para GPUs virtualizadas
Esta versión añade soporte para Intel GVT-g para KVM (KVMGT), una solución de virtualización de GPU, que está disponible a partir de la 4ª generación de procesadores Intel Core con Intel Graphics. Esta característica está basada en un nuevo framework de "Mediated devices" de VFIO. A diferencia de las soluciones de pass-through, los "dispositivos mediados" permiten que KVMGT ofrezca una GPU virtualizada que ofrece todas las características de una GPU real a todos y cada uno de los huéspedes virtualizados, al mismo tiempo que se mantiene un rendimiento casi similar al nativo. Para más detalles, ver estos papers:
A Full GPU Virtualization Solution with Mediated Pass-Through
KVMGT: a Full GPU Virtualization Solution
vGPU on KVM (video)
Intel GVT main site
· Nueva herramienta 'perf c2c' para el análisis de contención de cachelines
En los sistemas modernos con múltiples procesadores, los módulos de memoria están conectados físicamente a diferentes CPUs. En estos sistemas, llamados NUMA, los accesos de una CPU a la memoria del módulo que tiene conectado son más rápidos que los accesos a los módulos conectados a otros procesadores. Cuando un proceso tiene muchos hilos, cada hilo puede ejecutarse en diferentes CPUs al mismo tiempo; si esos hilos intentan acceder y modificar la misma memoria, pueden tener problemas de rendimiento debido a los costes en que se incurre para mantener los caches de las CPUs coordinados.
perf c2c (de "cache to cache") es una nueva herramienta diseñada para analizar y encontrar esta clase de problemas de rendimiento en sistemas NUMA. Para más detalles, ver https://joemario.github.io/blog/2016/09/01/c2c-blog/
· Historial detallado de los eventos de la planificación de procesos con 'perf sched timehist'
'perf sched timehist' proporciona un análisis de los eventos de la planificación de procesos. Ejemplo: $ perf sched record -- sleep 1; perf sched timehist.
time cpu task name wait time sch delay run time [tid/pid] (msec) (msec) (msec) -------- ------ ---------------- --------- --------- -------- 1.874569 [0011] gcc[31949] 0.014 0.000 1.148 1.874591 [0010] gcc[31951] 0.000 0.000 0.024 1.874603 [0010] migration/10[59] 3.350 0.004 0.011 1.874604 [0011]1.148 0.000 0.035 1.874723 [0005] 0.016 0.000 1.383 1.874746 [0005] gcc[31949] 0.153 0.078 0.022
· Mejora de la gestión de escritura a disco
Desde el principio de los tiempos, el mecanismo encargado de escribir al disco los datos que los procesos han creado y que no han pedido escribir inmediatamente ("background writeback") ha tenido problemas. Cuando Linux escribe al disco todos esos datos en el transfondo, deberían tener poco impacto en los procesos que están ejecutándose. Pero desde hace muchísimo tiempo, no ocurre eso. Por ejemplo, si haces algo como $ dd if=/dev/zero of=foo bs=1M count=10k, o intentas escribir archivos a un dispositivo USB, e intentas arrancar una aplicación pesada, el inicio prácticamente se eternizará hasta que el proceso de escritura termine. Estos problemas ocurren porque las escrituras intensas llenan las colas de la capa de bloques, y otras peticiones de E/S tienen que esperar mucho para ser atendidas (para más detalles, este artículo de LWN).
Esta versión añade un mecanismo que intenta frenar las escrituras intensas e impide que se monopolicen las colas de la capa de bloques, lo cual debería proporcionar una mayor sensación de interactividad en el escritorio. Esta opción debe ser configurada y, como cualquier cambio de estas características, puede no ser perfecto en esta primera versión.
· Polling de bloques híbrido
Linux 4.4 añadió soporte para hacer polling en las peticiones a la capa de dispositivos de bloque. Se trata de un mecanismo a lo que NAPI hace en tarjetas de red, y puede mejorar el rendimiento para dispositivos de alto rendimiento (ej. NVM). Sin embargo, hacer polling constantemente puede consumir demasiada CPU, y en algunos casos incluso reducir el rendimiento. Esta versión de Linux incorpora un sistema híbrido: polling adaptativo. En lugar de hacer polling inmediatamente tras la petición de E/S, el kernel introduce un pequeño retraso. Por ejemplo, si el kernel espera que una petición de E/S vaya a ser atendida en 8 µsegundos, el kernel duerme durante 4 µsegundos, y luego empieza a hacer polling. Con este sistema híbrido, el kernel puede conseguir grandes reducciones de latencia como las del polling puro, pero sin tanto abuso de la CPU. Gracias a las mejoras en la obtención de estadísticas de la capa de bloques que han sido incluidas en esta versión, el kernel puede analizar el tiempo que tarda las peticiones de E/S en completarse y calcular automáticamente el tiempo que debería dormir
Este sistema híbrido está desactivado por defecto. Se ha añadido un nuevo archivo sysfs, /sys/block/
· Mejor soporte de dispositivos ARM como el Nexus 5 y 6 o Allwinner A64
Como evidencia de los progresos que se están haciendo para acercar las diferencias entre los kernels Android y Linux, esta versión añade soporte para socs ARM como:
- Huawei Nexus 6P (Angler)
- LG Nexus 5x (Bullhead)
- Nexbox A1 y A95X Android TV boxes
- placa de desarrollo Pine64 basada en Allwinner A64
- placa Globalscale Marvell ESPRESSOBin basada en Armada 3700
- Renesas "R-Car Starter Kit Pro" (M3ULCB)
· Permitir asignar programas eBPF a cgroups
Esta versión añade la capacidad de asociar programas eBPF a cgroups, con el propósito de que esos programas eBPF se apliquen automáticamente a todos los sockets de las tareas ubicadas en el cgroup. Se ha añadido un nuevo tipo de programa eBPF, BPF_PROG_TYPE_CGROUP_SKB. La llamada al sistema bpf(2) ha sido extendida con dos nuevos comandos, BPF_PROG_ATTACH y BPF_PROG_DETACH, que permiten asociar y disociar programas a un cgroup. Esta característica es configurable (CONFIG_CGROUP_BPF). Artículo LWN recomendado: Network filtering for control groups
Esta versión también añade un nuevo tipo de programa eBPF, BPF_PROG_TYPE_CGROUP_SOCK. Al igual que los programas BPF_PROG_TYPE_CGROUP_SKB, pueden ser asignados a un cgroup, para permitir la modificación de un campo, sk_bound_dev_if.
· Cache de writeback RAID5 y soporte de "failfast"
Esta versión implementa un nuevo caché de writeback RAID5 en el subsistema MD (Multiple Devices). Su objetivo es agregar varias escrituras para poder hacer una escritura de "franja" completa, y de ese modo reducir el coste del proceso "read-modify-write" que daña el rendimiento de RAID5. Es beneficiosa para las cargas que hacen grandes escrituras secuenciales seguidas de fsync, por ejemplo. Esta característica está desactivada por defecto.
Esta versión añade también soporte para "failfast". Los discos RAID que tengan muchos fallos de E/S serán marcados rápidamente como rotos, de modo que no se recurrirá a ellos en el futuro, lo cual puede mejorar la latencia de las peticiones de E/S.
· Soporte para Intel Cache Allocation Technology
Esta es una característica de CPUs Intel que permite asignar políticas en los cachés L2/L3; ej. a una tarea de tiempo real se le podría asignar exclusivamente un espacio de caché. Para más detalles, ver este artículo de LWN: Controlling access to the memory cache.
Y eso es todo. Como siempre, pueden encontrar la lista completa, y en inglés, en esta página.
Un placer, como siempre. Gracias por el trabajo Diego.
ResponderEliminarBuenas noches.
ResponderEliminarSoy el tocapelotas del post anterior. Retiro lo dicho. ESTO SI ES PUBLICAR RAPIDO.
Como siempre, leer el anális del nuevo kernel en español... una maravilla, y encima nada mas salir... "chapó" por ti.
Muchas gracias campeón.
Un saludo.
Buenas Diego:
ResponderEliminarComentarte, que he puesto un post mío en mi blog, sobre este asunto, yo ya tengo el kernel 4.10.0:
http://www.sjlopezb.es/2017/02/kernel-4100.html
Por el momento, la pega es, aún con el paquete kernel-package, pero lo solventarán estos días, si Dios quiere.
Saludos...
Hola de nuevo:
EliminarSolucionado:
http://www.sjlopezb.es/2017/02/ya-si-funciona-el-kernel-4100-con-la.html
Saludos...
Muchas gracias por la información.
ResponderEliminar