Lo que traerá Linux 2.6.28, parte II

Linus se me ha adelantado, pero aquí está: La segunda parte del resumen de las principales novedades del aún no publicado Linux 2.6.28 (lista completa en ingles, aqui). La primera parte fue dedicada a Ext4, la principal novedad de esta versión. He aquí un resumen del resto:

• GEM, el gestor de memoria gráfica: En la última década el hardware gráfico ha evolucionado a un ritmo asombroso. Las GPUs de hoy tienen una inmensa capacidad de cálculo que tradicionalmente (utilizar esta palabra al hablar de la evolución del mundo informático tiene cierta ironía) solo ha sido aprovechada por aplicaciones especializadas que hacen uso de opengl/directx, como juegos y el diseño 3D; los escritorios 2D que todo el mundo conoce y utiliza han seguido usando este hardware moderno del mismo modo que usaban el antiguo, el que inició la "revolución del escritorio" en los 80-90. Es decir, con métodos ineficientes. Hay mucha potencia de cálculo en las GPUs que no se utiliza al menos que uses un juego. Por otra parte, la arquitectura del subsistema gráfico de Linux está lejos de considerarse perfecta, incluso desde el punto de vista de la arquitectura gráfica del hardware antiguo. Para empezar, hay varios drivers luchando para conseguir acceso al mismo recurso (la tarjeta gráfica): La consola basada en el framebuffer, la consola VGA sin framebuffer, el driver DRM que está dentro del kernel, el driver 2D de X.org que funciona en espacio de usuario...esta situación provoca toda clase de problemas y proporciona un rendimiento subóptimo.
  
  Se ha trabajado mucho en los últimos años para modernizar la arquitectura gráfica de Linux de manera que esté bien diseñada y que sea capaz de utilizar toda la potencia de las GPUs modernas y futuras. En 2.6.28, Linux incluye una de las partes más importantes de esa arquitectura: Un gestor de memoria para la memoria de la GPU, llamado GEM ("Graphic Execution Manager"). El propósito es disponer de un gestor central para gestionar "objetos buffer", su localización, su cacheado, su mapeado y su sincronización. En los cimientos de GEM se están construyendo muchas otras mejoras : Kernel Modesetting, DRI2, UXA (una implementación de EXA basada en GEM).
  
  Todo este código ha sido retrasado durante bastante tiempo, debido a que había un gestor de memoria anteriormente, llamado TTM, que casi fue incluido en Linux 2.6.24, hasta que de repente la gente de Intel apareció con las primeras versiones de GEM. Se decidió que éste era mejor que TTM, y se consideró necesario retrasar la inclusión de TTM y la renovación de toda la arquitectura gráfica para estabilizar GEM. Esta es la razón por la que en esta versión GEM solo funciona con el driver i915, y el soporte de X.org solo está implementado en la versión 2.5.0 del driver Intel. Existen parches preliminares que ofrecen soporte para otros drivers que serán incluidos en futuras versiones.


• Soporte de "Ultra Wide Band" (WB), USB inalámbrico y UWB-IP: UWB es una un protocolo de comunicación punto-a-punto de bajo consumo y alta velocidad, que utiliza un amplio espectro (3.1-10.6 GHz). Está optimizado para comunicaciones dentro den el espacio de una habitación (480Mbps a 2 metros, 110Mbps a 10). Sirve como capa de transporte a otros protocolos, como el USB inalámbrico, el protocolo de enlace WiMedia (Ethernet/IP sobre UWB) y, en el futuro, Bluetooth y 1394. Linux 2.6.28 añade el código necesario para implementar una pils UWB, así como drivers para los dispositivos más comunes


• Escalabilidad de la gestión de memoria:
  • Mejoras al algoritmo de reemplazo de páginas: Los sistemas con mucha memoria tienen muchas (millones) de páginas. Cuando el algoritmo de reemplazo tiene que buscar una página candidata a ser enviada al swap, tiene que buscar entre todas las páginas, y en los grandes sistemas esta puede ser una tarea muy costosa. En 2.6.28, las páginas respaldadas por archivos (páginas correspondientes al cache de un archivo y que una vez descartadas de la memoria pueden volver a ser leidas de ese archivo) y las páginas anónimas (las que no corresponden a ningun archivo -por ejemplo las obtenidas a través de malloc()- y que, por lo tanto, tienen que ser escritas en el swap antes de ser descartadas de la memoria) son clasificadas en dos listas diferentes, en lugar de una sola, como sucedía anteriormente. Los algoritmos encargados de seleccionar una página pueden por lo tanto mirar en una de esas listas sin tener que mirar la otra. Tambien existen páginas que no pueden ser descartadas de la memoria en absoluto, por ejemplo, las que están mlock()eadas, o las pertenecientes a un sistema de archivos ramfs. Esas páginas se ubican en una tercera lista que no será consultada por ningún algoritmo de selección de páginas, por la simple razón de que no puede descartarse ninguna de ellas.
  
  
  • Reescritura de la capa vmap: En 2.6.28, se ha reescrito el asignador vmap utilizando rbtrees y flusheado "vago" de la TBL, para proporcionar una implementación rapida y escalable. Algunas comparativas que ejercitan este asignador se han acelerado por 20 o más.


• Congelador de procesos de containers: El congelador de procesos de containers es un subsistema implementado como cgroup que utiliza el congelador de procesos de la suspensión por software para congelar y reiniciar grupos de procesos arbitrariamente escogidos por el usuario. Es inmediatamente útil para ir encolando scripts de mantenimiento. Será tambien útil en el futuro para implementar reinicio y checkpointing de containers.


• Traceador de arranque: El proposito de este traceador es ayudar a los desarrolladores a optimizar los tiempos de inicio: guarda los tiempos de las initcalls. Su propósito es ser parseado por el script hallado en scripts/bootgraph.pl para crear gráficos que muestren las ineficiencias del proceso de arranque, dando una representación visual de los retrasos que hay entre las initicalls. Los usuarios tendrán que activar CONFIG_BOOT_TRACER, y arrancar el kernel con los parámetros "initcall_debug" y "printk.time=1" (este último si no se tiene activada las marcas de tiempo en cada mensaje de dmesg), y ejecutar "dmesg | perl scripts/bootgraph.pl > output.svg" para generar los gráficos.


• Protección del disco contra golpes: El estándar ATA/ATAPI-7 especifica los detalles sobre el comando IDLE IMMEDIATE. Enviar este comando debería hacer que la unidad se pusiera en modo de reposo y descargara los cabezales del disco. Esta característica se utiliza en los portátiles modernos junto a acelerómetros y un software apropiado para implementar una herramienta de protección del disco. La idea es detener todas las operaciones de I/O del disco y aparcar los cabezales cuando se puedan anticipar situaciones criticas.
  
  Para cada dispositivo ATA, Linux 2.6.28 añade el archivo /sys/block/*/device/unload_heads. Escribiendo un valor entero a este archivo apartará los cabezales del respectivo dispositivo de los platos del disco durante el número especificado de milisegundos. Cuando el temporizador expira, las operaciones continuan normalmente. El máximo valor aceptado son 30.000 milisegundos (30 segundos). Sin embargo, existen algunos discos duros que solamente cumplen con una versión anterior del estándar ATA, pero que soportan esta característica de todos modos. Desgraciadamente, no hay una manera segura que Linux pueda utilizar para detectar esos dispositivos, asi que para ellos no se podrá escribir en su archivo unload_heads. Si sabes que tu disco duro verdaderamente lo soporta (por ejemplo, porque quien te vendió el portátil te lo ha dicho), entonces puedes ordenar al kernel que lo active escribiendo el valor especial -1 al archivo. Lee esta página para más información de como Linux soporta la protección de discos duros de los Thinkpads IBM/Lenovo.


• Protocolo de red Phonet: El protocolo "Phone Network" (PhoNet) es un protocolo de comunicación orientado a paquetes que ha sido desarrollado por Nokia para ser utilizado en los módems de sus móviles tanto para IPC como RPC. Con la familia de sockets Phonet, los procesos pueden enviar y recibir y enviar mensajes de/hacia el modem, o de cualquier otro dispositivo externo conectado al modem; el modem se ocupa del ruteo. Los paquetes Phonet pueden ser enviados a través de diferentes conexiones hardware: USB con la interfaz CDC Phonet, infrarrojos, Bluetooth, un puert serie.... Este protocolo es un requisito para que Maemo pueda utilizar la conectividad de móviles; tambien puede usarse para controlar móviles Nokia.


• Redes: Proxying transparente, nuevos drivers, DSA...
  • Soporte de la Arquitectura Distribuida de Switchs (DSA): DSA es un protocolo para gestionar los chips de los switchs. Los switchs que este driver soporta son los que se pueden encontrar embebidos típicamente en routers y puntos de acceso.
  
  
  • Soporte de proxying transparente: Esta característica (perdida hace 5 años) permite el proxying transparente, es decir, soporte para gestionar sockets IPv4 TCP y UDP no locales. Añade un target de iptables "TPROXY", que es algo parecido a "REDIRECT". Solo puede ser utilizado en la tabla "mangle" y es útil para redireccionar tráfico a un proxy transparente. No depende de NAT, a diferencia de REDIRECT.
  
  
  • Nuevos drivers de red: Esta version añade unos cuantos drivers nuevos: atl2, SMSC LAN9500 USB2.0 10/100, enic: Cisco 10G Ethernet, qlge: Qlogic 10Gb Ethernet, jme: JMicron Gigabit Ethernet


• Tracepoint: Los tracepoints son otro mecanismo para insertar puntos estáticos de trazado, que es utilizado por herramientas como LTT (Linux Trace Toolkit).


• Drivers -staging: Dentro del kernel Linux existe una controversia entre la gente que piensa que los drivers nuevos deberían ser incluidos lo antes posible en el kernel, siendo aun de mala debido a su corta edad; y la gente que piensa que solo deberían incluise drivers con ciertos niveles de alta calidad. Para solucionarlo, se ha creado un repositorio llamado "-staging", en el que se incluyen varios drivers de los que son muy nuevos y suelen encontrarse en sus propias páginas web y no en el repositorio principal de Linux. Estos drivers se ubican en drivers/staging y son mantenidos ahí mientras no tengan la calidad necesaria. En el log completo en inglés se puede leer la lista de drivers -staging incluidos en esta versión.


• FIEMAP: Cuando una aplicación quiere saber como se ha almacenado un archivo en el disco (por ejemplo, un programa de copia de seguridad que quiere saber si un archivo es del tipo "sparse", para no tener que copiarle entero), utiliza la ioctl fibmap. Pero esta ioctl es subóptima - solo puede pedir información sobre un solo bloque cada vez, lo cual es demasiado ineficiente en el caso de grandes archivos. La ioctl FIEMAP sin embargo devuelve una lista de extents, permitiendo devolver la información de un archivo en una sola llamada