Lo que traerá el Linux Kernel 2.6.27

Por leprosys en 9/23/2008 ,




Descripción
Creo que muchos esperan ver las nuevas mejoras del kernel, sobre todo cuando algunos dispositivos no trabajan del todo bien en nuestro sistema, en el blog D'Oh! han traducido algunas de las nuevas mejoras que traerá el kernel 2.6.27 (lista completa en ingles, aqui):
  • page cache y get_user_pages() sin bloqueos (lockless): El page cache es el lugar (de la RAM) donde el kernel pone copias de los archivos que están en el disco para acelerar el rendimiento. Cada instancia de la estructura "mapping" almacena la información de cada archivo que tiene copias de sus datos en el page cache. Esa estructura tiene un bloqueo para evitar problemas de concurrencia cuando se accede a ella. Si hay varios procesos que están accediendo a esa estructura simultáneamente -lo cual, para ser sinceros, no es algo muy común ni es por lo general un problema- puede formarse cierta contención en ese bloqueo. Para resolverlo, en Linux 2.6.27 las operaciones de lectura de las estructuras del page cache se harán sin necesidad de adquirir ese bloqueo. Debido al diseño, en el que se evitan también ciertas operaciones costosas, tambien se ha mejorado el tiempo de lectura y modificación del page cache en sistemas monoprocesador.

    get_user_pages(): Existe una técnica llamada Direct I/O, que consiste en hacer operaciones de I/O saltándose completamente el page cache y todo tipo de gestión de memoria del kernel. Las grandes bases de datos son quienes suelen utilizar estas cosas, porque ellas mismas hacen su propia gestión de memoria a su gusto. get_user_pages() es una función interna del kernel encargada de copiar los datos de la memoria del proceso a la memoria del kernel cuando se hace Direct I/O para posteriormente escribirlo en el disco. Sin embargo, esta función requiere adquirir un par de bloqueos importantes, que hacen que se forme cierta contención cuando hay varios threads usando get_user_pages() en un mismo espacio de direcciones. En 2.6.27 se ha añadido la función get_user_pages_fast(), cuya función básica es la misma, pero esta diseñada para gestionar los casos mas comunes y por tanto puede prescindir de 4 de los 8 argumentos que toma la otra funciona, y puede hacer Direct I/O sin tomar ningún bloqueo. Eso hace que las operaciones de Direct I/O se aceleren considerablemente - un 10% en un benchmark OLTP sobre DB2 en una maquina Intel Quadcore.

  • Ext4: delayed allocation: Esta es una de las grandes promesas de ext4. Se trata de algo que no afecta al formato del disco, es un mero problema de implementación. En los SO modernos, cuando una aplicación escribe algo al disco no lo escribe inmediatamente, sino que lo guarda en buffers que serán escritos posteriormente. Sin embargo, por comodidad, la mayoría de sistemas de archivos implementan esta función como un caso particular de la función general "escribir los datos en el disco". Me explico: en la mayor parte de sistemas de archivos, cuando la aplicación hace write(), lo que suele hacer el sistema de archivos es llamar a las rutinas de asignacion de bloques libres a los nuevos datos, actualizar el contador de espacio libre, etc....a pesar de que los datos aun no se están escribiendo y van a pasar un rato en los buffers. Esto es suboptimo por muchas y variadas razones; por ejemplo, un archivo puede consistir de varios write()s y el algoritmo de asignación de bloques no puede saberlo cuando recibe el primer write(), y por tanto no puede encontrarle un lugar adecuado. La técnica "delayed allocation" consiste, simplemente, en no llamar a esas rutinas de asignación de bloques, solo la de actualizar el contador de espacio libre. La asignacion del espacio que los datos van a ocupar en el disco se realiza solamente cuando los datos se van a escribir verdaderamente en el disco. Esta tecnica, utilizada por sorprendentemente pocos sistemas de archivos -XFS, ZFS, reiser 4 y btrfs-, mejora el rendimiento en muchos tipos de carga -en algunos las mejoras son astronómicas y disminuye la fragmentación.

  • UBIFS: UBIFS es un sistema de archivos diseñado por Nokia para dispositivos de almacenamiento flash puros. Cuando digo puros, me refiero a que no puede utilizarse en los típicos lapices USB o discos externos USB hechos con memoria flash. Ese tipo de dispositivos tiene una capa de emulación que los hace parecer, al exterior, como un dispositivo de bloques normal y corriente. UBIFS esta diseñado para los sistemas que no tienen esa capa. Es mejor que JFFS2 en varios aspectos: rendimiento, el montaje inicial es rápido, resistencia a reinicios a lo bruto...

  • Kexec jump: hibernación basada en kexec/kdump: Kexec es un sistema que permite cargar un kernel Linux en memoria y ejecutarlo directamente desde el kernel que estas corriendo, sin necesidad de reiniciar. Kdump es un sistema de volcado de memoria del kernel basado en kexec: Se carga al principio del sistema un kernel a prueba de fallos en memoria, y si hay un fallo en el kernel, el código de OOPS llama a kexec, ejecuta el kernel a prueba de fallos, se carga ese kernel, y se copia el resto de la memoria del sistema a un archivo - el volcado de memoria. En 2.6.27, estos sistemas se han extendido para una nueva función: hibernar el sistema. Se carga un kernel, se ejecuta, ese kernel guarda el contenido de la memoria en un archivo, y se apaga el sistema. Al encender de nuevo el sistema, se carga el archivo con la memoria y se sigue ejecutando.

  • Soporte de integridad de datos en la capa de bloque: Hay sistemas de archivos capaces de usar checksums para detectar corrupcion en un archivo. Sin embargo, esto se detecta solamente al leerlo. SCSI y ATA estan preparando especificaciones y dispositivos que junto a los resultados de las operaciones de escritura devuelven al kernel un CRC de cada sector escrito para que se verifique si no ha habido errores.

  • ftrace: ftrace es un sistema de instrumentalización del código muy simple nacido en el seno de los parches -rt: se utiliza una extensión de gcc para dejar 5 bytes de NOPs en el principio de todas y cada una de las funciones del kernel (no tiene ningún efecto en el rendimiento, incluso en microbenchmarks: las CPUs modernas han optimizado este tipo de secuencias muy bien). Cuando ftrace se activa, esos NOPs se modifican con instrucciones que llaman a ftrace para tomar nota de las funciones que se van llamando. Es muy útil para analizar el rendimiento de diferentes partes del cogido. Pero la parte mas útil es que ftrace tiene una infraestructura de plugins que ha permitido desarrollar todo tipo de funciones: se pueden analizar los cambios de contexto, la latencia que sufre un proceso desde que es "despertado" por el gestor de procesos hasta que finalmente empieza a ejecutarse, tiempo máximo que se pasa con las interrupciones desactivadas, el tiempo gastado en porciones de código donde se deshabilita preempt...además de soporte de sysprof.

  • mmiotrace: Instrumentalización de las operación de mmio (memory-mapped I/O: I/O que se hace mapeando parte de la memoria a un dispositivo y escribiendo en la misma). Por lo visto es muy útil para hacer ingeniería inversa de los drivers de nvidia^W^Wpropietarios.

  • Capa de red multicola: En las tarjetas de red modernas, especialmente las wireless, asten apareciendo múltiples colas, en vez de la tradicionalmente única: Una para voz, otra para vídeo, otra de baja prioridad para P2P^W"trafico de fondo". En 2.6.27 la capa de red tiene soporte para este tipo de dispositivos.

  • Firmware externo: El firmware de los drivers ha sido extraído de los mismos y centralizado en el directorio firmware/. Este firmware puede ser instalado en /lib/firmware, de manera que cuando los drivers lo necesiten, se llamara al programa que carga firmware externo desde un archivo del disco duro, algo que apreciaran los enfermos de GNUitis. También se puede optar, para quien no les guste esto, por meter todo el firmware en la imagen del kernel.

  • Soporte de webcams mejorado: Se ha incluido el driver gspca, que incluye soporte para la mayor parte de las webcams que quedaban por soportar en Linux.

  • syscalls que crean descriptores de archivo extendidas: UNIX no fue perfecto. Por ejemplo, muchas de las diversas rutinas que crean descriptores de archivo no permiten crear descriptores de archivo con ciertas propiedades que hoy en día se utilizan. Resulta que poder hacerlo no es un simple capricho - también existen ciertos aspectos de esta carencia que pueden vulnerar la seguridad. Para solucionar este problema no había otro remedio que añadir un porrillo de syscalls nuevas que aceptaran los parámetros necesarios. Aunque parezca algo sucio tener que añadir estas nuevas syscalls, lo cierto es que añadirlas es bastante "barato" y no se ha añadido casi nada de código.

  • Soporte de chips intel wireless 5000, chips wireless Atheros AR5008 y AR9001, soporte de tarjetas de red Realtek RTL8187y de Atheros L1E Gigabit, muchos otros drivers, soporte mejorado de drivers ya existentes, muchas otras mejoras y pequeños arreglos. Lista completa de cambios aqui.

Vía | D'Oh!

Back Top