Falta poco tiempo (una semana o asi) para que salga Linux 2.6.27. He aqui un resumen de las principales novedades:
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 estan en el disco para acelerar el rendimiento. Cada instancia de la estructura "mapping" almacena la informacion 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 estan accediendo a esa estructura simultaneamente -lo cual, para ser sinceros, no es algo muy comun ni es por lo general un problema- puede formarse cierta contencion en ese bloqueo. Para resolverlo, en Linux 2.6.27 las operaciones de lectura de las estructuras del page cache se haran sin necesidad de adquirir ese bloqueo. Debido al diseño, en el que se evitan tambien ciertas operaciones costosas, tambien se ha mejorado el tiempo de lectura y modificacion del page cache en sistemas monoprocesador.
get_user_pages(): Existe una tecnica llamada Direct I/O, que consiste en hacer operaciones de I/O saltandose completamente el page cache y todo tipo de gestion de memoria del kernel. Las grandes bases de datos son quienes suelen utilizar estas cosas, porque ellas mismas hacen su propia gestion de memoria a su gusto. get_user_pages() es una funcion 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 funcion requiere adquirir un par de bloqueos importantes, que hacen que se forme cierta contencion cuando hay varios threads usando get_user_pages() en un mismo espacio de direcciones. En 2.6.27 se ha añadido la funcion get_user_pages_fast(), cuya funcion basica 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 funcion, y puede hacer Direct I/O sin tomar ningun 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 implementacion. En los SO modernos, cuando una aplicacion escribe algo al disco no lo escribe inmediatamente, sino que lo guarda en buffers que seran escritos posteriormente. Sin embargo, por comodidad, la mayoria de sistemas de archivos implementan esta funcion como un caso particular de la funcion general "escribir los datos en el disco". Me explico: en la mayor parte de sistemas de archivos, cuando la aplicacion 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 estan 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 asignacion de bloques no puede saberlo cuando recibe el primer write(), y por tanto no puede encontrarle un lugar adecuado. La tecnica "delayed allocation" consiste, simplemente, en no llamar a esas rutinas de asignacion 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 astronomicas- y disminuye la fragmentacion.
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 tipicos lapices USB o discos externos USB hechos con memoria flash. Ese tipo de dispositivos tiene una capa de emulacion 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 rapido, resistencia a reinicios a lo bruto...
Kexec jump: hibernacion 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 codigo 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 funcion: 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 instrumentalizacion del codigo muy simple nacido en el seno de los parches -rt: se utiliza una extension de gcc para dejar 5 bytes de NOPs en el principio de todas y cada una de las funciones del kernel (no tiene ningun 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 util para analizar el rendimiento de diferentes partes del codigo. Pero la parte mas util 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 maximo que se pasa con las interrupciones desactivadas, el tiempo gastado en porciones de codigo donde se deshabilita preempt...ademas de soporte de sysprof.
mmiotrace: Instrumentalizacion de las operacion 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 util para hacer ingenieria inversa de los drivers de nvidia^W^Wpropietarios.
Capa de red multicola: En las tarjetas de red modernas, especialmente las wireless, estan apareciendo multiples colas, en vez de la tradicionalmente unica: Una para voz, otra para video, 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 extraido 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. Tambien 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 dia se utilizan. Resulta que poder hacerlo no es un simple capricho - tambien existen ciertos aspectos de esta carencia que pueden vulnerar la seguridad. Para solucionar este problema no habia otro remedio que añadir un porrillo de syscalls nuevas que aceptaran los parametros 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 codigo.
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.
fuente
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 estan en el disco para acelerar el rendimiento. Cada instancia de la estructura "mapping" almacena la informacion 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 estan accediendo a esa estructura simultaneamente -lo cual, para ser sinceros, no es algo muy comun ni es por lo general un problema- puede formarse cierta contencion en ese bloqueo. Para resolverlo, en Linux 2.6.27 las operaciones de lectura de las estructuras del page cache se haran sin necesidad de adquirir ese bloqueo. Debido al diseño, en el que se evitan tambien ciertas operaciones costosas, tambien se ha mejorado el tiempo de lectura y modificacion del page cache en sistemas monoprocesador.
get_user_pages(): Existe una tecnica llamada Direct I/O, que consiste en hacer operaciones de I/O saltandose completamente el page cache y todo tipo de gestion de memoria del kernel. Las grandes bases de datos son quienes suelen utilizar estas cosas, porque ellas mismas hacen su propia gestion de memoria a su gusto. get_user_pages() es una funcion 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 funcion requiere adquirir un par de bloqueos importantes, que hacen que se forme cierta contencion cuando hay varios threads usando get_user_pages() en un mismo espacio de direcciones. En 2.6.27 se ha añadido la funcion get_user_pages_fast(), cuya funcion basica 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 funcion, y puede hacer Direct I/O sin tomar ningun 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 implementacion. En los SO modernos, cuando una aplicacion escribe algo al disco no lo escribe inmediatamente, sino que lo guarda en buffers que seran escritos posteriormente. Sin embargo, por comodidad, la mayoria de sistemas de archivos implementan esta funcion como un caso particular de la funcion general "escribir los datos en el disco". Me explico: en la mayor parte de sistemas de archivos, cuando la aplicacion 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 estan 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 asignacion de bloques no puede saberlo cuando recibe el primer write(), y por tanto no puede encontrarle un lugar adecuado. La tecnica "delayed allocation" consiste, simplemente, en no llamar a esas rutinas de asignacion 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 astronomicas- y disminuye la fragmentacion.
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 tipicos lapices USB o discos externos USB hechos con memoria flash. Ese tipo de dispositivos tiene una capa de emulacion 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 rapido, resistencia a reinicios a lo bruto...
Kexec jump: hibernacion 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 codigo 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 funcion: 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 instrumentalizacion del codigo muy simple nacido en el seno de los parches -rt: se utiliza una extension de gcc para dejar 5 bytes de NOPs en el principio de todas y cada una de las funciones del kernel (no tiene ningun 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 util para analizar el rendimiento de diferentes partes del codigo. Pero la parte mas util 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 maximo que se pasa con las interrupciones desactivadas, el tiempo gastado en porciones de codigo donde se deshabilita preempt...ademas de soporte de sysprof.
mmiotrace: Instrumentalizacion de las operacion 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 util para hacer ingenieria inversa de los drivers de nvidia^W^Wpropietarios.
Capa de red multicola: En las tarjetas de red modernas, especialmente las wireless, estan apareciendo multiples colas, en vez de la tradicionalmente unica: Una para voz, otra para video, 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 extraido 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. Tambien 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 dia se utilizan. Resulta que poder hacerlo no es un simple capricho - tambien existen ciertos aspectos de esta carencia que pueden vulnerar la seguridad. Para solucionar este problema no habia otro remedio que añadir un porrillo de syscalls nuevas que aceptaran los parametros 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 codigo.
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.
fuente
No hay comentarios
Publicar un comentario