30 de agosto de 2010
Curiosidades python
Me ha parecido curiosa esta manera de corregir un typo en todas las páginas de un wiki. No sabía que existían este tipo de librerías, python siempre logra sorprenderme.
27 de agosto de 2010
Novedades en systemd
Desde que Lennart Poettering, autor de Pulseaudio, anunció el nacimiento de systemd, un reemplazo de init/upstart (si quieren, también pueden leer el enlace anterior en este otro sitio en el que me copian el texto del blog sin poner ni una cita), han pasado 4 meses. Suele pasar en ocasiones que un proyecto sale a la luz y la luz lo seca o lo debilita como a un brote reciente (caso de Wayland, tan revolucionario y tan raquítico a la vez). No ha sido este caso. Systemd se ha saltado etapas de crecimiento a una velocidad pasmosa y ya se acerca a árbol, como puede comprobarse en este post de Lennart sobre la evolución del proyecto.
En primer lugar, han implementado los varios tipos de "unidades" que habían prometido y faltaban. Han añadido las unidades timer. Su propósito es sustituir la funcionalidad de cron (aunque de un vistazo a la documentación es evidente que aun le falta funcionalidad para lograrlo por completo). Otro tipo de unidad es path, que puede utilizarse para invocar automáticamente un servicio cuando hay actividad en alguna parte del sistema de archivos, o cuando se crea un directorio determinado (es, por así decirlo, una especie de herramienta para usar inotify). Y el último tipo de unidad implementado es swap, que indica a systemd las particiones de intercambio que hay que montar (recordemos que, entre otras cosas, systemd pretende conseguir que /etc/fstab sea teóricamente innecesario).
Otra novedad importante es que systemd se ha integrado con todo lo que ha encontrado por delante: SELinux a la hora de crear directorios o sockets, TCP wrappers, PAM, y los inicios/paradas de los servicios se reportan al sistema de auditoría del kernel. También se ha integrado el sistema con D-Bus, de modo que los servicios que utilicen las interfaces D-Bus para comunicarse con los clientes pueden informar de ello en sus archivos de configuración, y systemd se encargará de arrancar automáticamente esos servicios cuando un cliente intente comunicarse con él (básicamente se trata de lo mismo que se hace con los sockets de red, pero aplicado a las conexiones D-BUS).
Otra novedad, muy curiosa, es cómo han utilizado las características de systemd para conseguir que no se pierda absolutamente ningún mensaje destinado a archivos log, desde el arranque del sistema hasta su apagado. Nada más iniciarse, systemd se pone a escuchar en el socket /dev/log, y envía los mensajes que allí se envían al buffer del kernel (el de dmesg). Posteriormente se arranca syslog (a quien se cede el control de /dev/log), el cual, como primera operación, guarda ese buffer del kernel en el disco. De ese modo, no se pierde ni un solo mensaje. Es más, si syslog muere por cualquier razón, o cuando el sistema se está apagando y hay que apagar el proceso, se restablece la comunicación /dev/log -> dmesg.
Respecto a la adopción, parece que systemd va a ser el sistema de inicio por defecto para Fedora 14. A esto ayuda, no cabe duda, que los mecanismos de systemd hacen posible convivir servicios con configuraciones systemd y otros con configuraciones antiguas sin que haya problemas de ningún tipo. Upstart necesitó ser tremendamente conservador para evitar problemas (pagando como precio el no estar aun terminado, de acuerdo con su autor). Systemd no necesita tantos cuidados. Quizás sea esa la razón por la que ya hay paquetes y scripts disponibles para OpenSUSE, Debian, Gentoo y Arch. Aunque en Debian habría problemas para utilizarlo como sistema de inicio por defecto, porque systemd sólo funciona para Linux y Debian está empeñada en soportar kernels BSD...
En primer lugar, han implementado los varios tipos de "unidades" que habían prometido y faltaban. Han añadido las unidades timer. Su propósito es sustituir la funcionalidad de cron (aunque de un vistazo a la documentación es evidente que aun le falta funcionalidad para lograrlo por completo). Otro tipo de unidad es path, que puede utilizarse para invocar automáticamente un servicio cuando hay actividad en alguna parte del sistema de archivos, o cuando se crea un directorio determinado (es, por así decirlo, una especie de herramienta para usar inotify). Y el último tipo de unidad implementado es swap, que indica a systemd las particiones de intercambio que hay que montar (recordemos que, entre otras cosas, systemd pretende conseguir que /etc/fstab sea teóricamente innecesario).
Otra novedad importante es que systemd se ha integrado con todo lo que ha encontrado por delante: SELinux a la hora de crear directorios o sockets, TCP wrappers, PAM, y los inicios/paradas de los servicios se reportan al sistema de auditoría del kernel. También se ha integrado el sistema con D-Bus, de modo que los servicios que utilicen las interfaces D-Bus para comunicarse con los clientes pueden informar de ello en sus archivos de configuración, y systemd se encargará de arrancar automáticamente esos servicios cuando un cliente intente comunicarse con él (básicamente se trata de lo mismo que se hace con los sockets de red, pero aplicado a las conexiones D-BUS).
Otra novedad, muy curiosa, es cómo han utilizado las características de systemd para conseguir que no se pierda absolutamente ningún mensaje destinado a archivos log, desde el arranque del sistema hasta su apagado. Nada más iniciarse, systemd se pone a escuchar en el socket /dev/log, y envía los mensajes que allí se envían al buffer del kernel (el de dmesg). Posteriormente se arranca syslog (a quien se cede el control de /dev/log), el cual, como primera operación, guarda ese buffer del kernel en el disco. De ese modo, no se pierde ni un solo mensaje. Es más, si syslog muere por cualquier razón, o cuando el sistema se está apagando y hay que apagar el proceso, se restablece la comunicación /dev/log -> dmesg.
Respecto a la adopción, parece que systemd va a ser el sistema de inicio por defecto para Fedora 14. A esto ayuda, no cabe duda, que los mecanismos de systemd hacen posible convivir servicios con configuraciones systemd y otros con configuraciones antiguas sin que haya problemas de ningún tipo. Upstart necesitó ser tremendamente conservador para evitar problemas (pagando como precio el no estar aun terminado, de acuerdo con su autor). Systemd no necesita tantos cuidados. Quizás sea esa la razón por la que ya hay paquetes y scripts disponibles para OpenSUSE, Debian, Gentoo y Arch. Aunque en Debian habría problemas para utilizarlo como sistema de inicio por defecto, porque systemd sólo funciona para Linux y Debian está empeñada en soportar kernels BSD...
19 de agosto de 2010
Dos pájaros de un tiro
A Oracle solo le faltó anunciar algo de MySQL para hacer triplete. Android y Opensolaris apuntalados por Larry Ellison el mismo día. Desde que se anuncio la compra de Sun todo fueron especulaciones sobre qué haría Oracle con su rutilante compra a precio de saldo, la más común en círculos linuxeros, incluido este blog, era la sospecha de que el señor Ellison antepondría absolutamente todo a su avaricia, como así ha sido. En fin, fue bonito mientras duró. Sirvan estas líneas de apoyo póstumo a Sun y su plan de apoyo al software libre.
Como ya saben, este blog se precia de no ser una de esas fotocopiadoras que regurgitan lo que otros escriben en la blogosfera, aquí se generan vómitos propios. Por lo tanto asumo que ustedes ya habrán leído la avalancha de noticias sobre el tema. Lo que le preocupa a este humilde servidor de ustedes es...¿y ahora qué?
El asunto de Android y su implementación de Java es peliagudo. Uno no acaba de adivinar el propósito de Oracle. Un sudor frío me recorre la espalda al pensar que tal vez quería la posesión de Java simplemente para exprimir la dependencia que de Java tienen quienes han escrito miles y miles de líneas de código en él. ¿Qué otra opción cabe? Si su intención es mantener la unidad de Java, nada les ayudará a lograr ese fin declararlo tecnología propiedad exclusiva de Oracle. A las plataformas de desarrollo y lenguajes de propósito general se les asume una libertad similar a la de los estándares de Internet. Que te demanden por no seguir un estándar o unas librerías al pie de la letra es una manera de decir: "Esto es nuestro, no se atreva a tocarlo, limítese a usar nuestros programas". Se dirá que Java en realidad sí es verdaderamente libre, con la pequeña condición de adherirse incondicionalmente al estándar, pero hay analogías, salvando las diferencias, con el modelo de sindicato único de ciertos regímenes.
Naturalmente, Oracle es libre de hacer lo que desee con su propiedad, pero Java ya no será verdaderamente libre, al menos para sus usuarios. Y esto es un cambio radical para el que sigue siendo uno de los principales lenguajes de programación del mundo. Porque una de las claves para la construcción del imperio de Java fue una especie de consenso con el resto de la industria. La única razón por la que una compañía como IBM apoyó con tanta fuerza este lenguaje creado por el que en su día era quizás su más fiero competidor, es que sabían que Sun jamás se iba a aprovechar de su posición para fastidiar a los clientes de IBM. Es de imaginar que los señores de Big Blue estarán hoy pero que muy enfadados y preocupados por este rumbo escogido por Oracle. De hecho, teniendo en cuenta que Larry Ellison ha declarado a IBM como su mayor enemigo, ¿no es posible que las adquisición de Java no tenga otro objetivo que fastidiar a IBM?
El tema de OpenSolaris es menos preocupante, porque podemos ser cínicos y tomarlo como buenas noticias para Linux. Por muy Linuxero que uno fuera, en su día la liberación de Solaris solo cabía aceptarse como buena, muy buena noticia para el software libre. Pero ahora, aunque el software libre salga perdiendo, Linux en particular sale reforzado, ya que el escenario principal de sistemas operativos de software libre vuelve a ser exclusivamente suyo. Incluso si Oracle hace de Solaris un gran sistema operativo, con más maravillas del tipo de ZFS, sus competidores por inercia invertirán en Linux...en los hilos de los sitios de noticias, hay personas interesadas en dejar OpenSolaris y volver a Linux (o al menos a FreeBSD, que por otra parte sale mal parado por todo este asunto). No se puede pillar a los usuarios de OpenSolaris igual que a los de Java. Así que vaya lo uno por lo otro.
Como ya saben, este blog se precia de no ser una de esas fotocopiadoras que regurgitan lo que otros escriben en la blogosfera, aquí se generan vómitos propios. Por lo tanto asumo que ustedes ya habrán leído la avalancha de noticias sobre el tema. Lo que le preocupa a este humilde servidor de ustedes es...¿y ahora qué?
El asunto de Android y su implementación de Java es peliagudo. Uno no acaba de adivinar el propósito de Oracle. Un sudor frío me recorre la espalda al pensar que tal vez quería la posesión de Java simplemente para exprimir la dependencia que de Java tienen quienes han escrito miles y miles de líneas de código en él. ¿Qué otra opción cabe? Si su intención es mantener la unidad de Java, nada les ayudará a lograr ese fin declararlo tecnología propiedad exclusiva de Oracle. A las plataformas de desarrollo y lenguajes de propósito general se les asume una libertad similar a la de los estándares de Internet. Que te demanden por no seguir un estándar o unas librerías al pie de la letra es una manera de decir: "Esto es nuestro, no se atreva a tocarlo, limítese a usar nuestros programas". Se dirá que Java en realidad sí es verdaderamente libre, con la pequeña condición de adherirse incondicionalmente al estándar, pero hay analogías, salvando las diferencias, con el modelo de sindicato único de ciertos regímenes.
Naturalmente, Oracle es libre de hacer lo que desee con su propiedad, pero Java ya no será verdaderamente libre, al menos para sus usuarios. Y esto es un cambio radical para el que sigue siendo uno de los principales lenguajes de programación del mundo. Porque una de las claves para la construcción del imperio de Java fue una especie de consenso con el resto de la industria. La única razón por la que una compañía como IBM apoyó con tanta fuerza este lenguaje creado por el que en su día era quizás su más fiero competidor, es que sabían que Sun jamás se iba a aprovechar de su posición para fastidiar a los clientes de IBM. Es de imaginar que los señores de Big Blue estarán hoy pero que muy enfadados y preocupados por este rumbo escogido por Oracle. De hecho, teniendo en cuenta que Larry Ellison ha declarado a IBM como su mayor enemigo, ¿no es posible que las adquisición de Java no tenga otro objetivo que fastidiar a IBM?
El tema de OpenSolaris es menos preocupante, porque podemos ser cínicos y tomarlo como buenas noticias para Linux. Por muy Linuxero que uno fuera, en su día la liberación de Solaris solo cabía aceptarse como buena, muy buena noticia para el software libre. Pero ahora, aunque el software libre salga perdiendo, Linux en particular sale reforzado, ya que el escenario principal de sistemas operativos de software libre vuelve a ser exclusivamente suyo. Incluso si Oracle hace de Solaris un gran sistema operativo, con más maravillas del tipo de ZFS, sus competidores por inercia invertirán en Linux...en los hilos de los sitios de noticias, hay personas interesadas en dejar OpenSolaris y volver a Linux (o al menos a FreeBSD, que por otra parte sale mal parado por todo este asunto). No se puede pillar a los usuarios de OpenSolaris igual que a los de Java. Así que vaya lo uno por lo otro.
2 de agosto de 2010
Las novedades de Linux 2.6.35
Linus ha anunciado la versión 2.6.35, como siempre aquí está la traducción castellana de las novedades principales. A vista de pájaro, esta versión añade soporte para repartir automáticamente la carga de red entrante entre varias CPUs, soporte de Direct I/O para Btrfs, un modo de journaling alternativo para XFS, inclusión de la interfaz del depurador KDB, varias mejoras de perf, aceleración de vídeo H.264 y VC1 en hardware Intel G45+, soporte del futuro Intel Cougarpoint, un sistema de defragmentación de la memoria, soporte de L2TP versión 3 (RFC 3931), varios drivers y muchas pequeñas mejoras más. Lista completa en inglés aquí.
· Reparto automático entre varias CPUs del tráfico de red de entrada: Las tarjetas de red actuales han mejorado su rendimiento hasta el punto de que para una sola CPU moderna es cada vez más difícil mantener el ancho de banda de recepción al máximo. Dos nuevas características, contribuidas por Google, ayudan a repartir automáticamente la carga de los paquetes de red entrantes entre varias CPUs (los salientes ya se reparten por si solos). El procesado de protocolos(IP, TCP) se ha modificado para que pueda hacerse en paralelo. Cada dispositivo de red utiliza diferentes heurísticas para decidir en qué CPU se procesará el paquete (hash de la cabecera del paquete, afinidad con la CPU en la que se está ejecutando la aplicación que lo va a recibir). Esta característica emula por software lo que una tarjeta de red multiqueue hace en hardware. Un benchmark de 500 instancias del test netperf TCP_RR con 1 byte de petición y respuesta en una e1000e montada en un servidor con CPU Intel de 8 cores ascienden de 104K tps a 303K tps. Un test RPC con 100 threads en cada host, va de 103K tps a 223K, y con menos latencia.
· Mejoras Btrfs: Direct I/O y -ENOSPC completo. Direct I/O es una técnica utilizada para saltarse el caché a la hora de escribir. Esto daña el rendimiento (es como montar un sistema de archivos en modo "sync"), pero es utilizado extensivamente en grandes bases de datos a las que les gusta implementar su propio cache optimizado. -ENOSPC completo: Linux 2.6.32 ya tenía soporte de -ENOSPC para el uso común del sistema de archivos, pero existían varios casos raros en ciertas operaciones complejas, como operaciones de gestión de volumenes, en los que podía haber fallos. El código -ENOSPC de esta versión maneja correctamente todos los casos: balanceo de espacio libre, gestión de discos, logging de fsync y otros.
· XFS delayed logging: Esta versión añade un nuevo modo de journaling para XFS llamado "delayed logging", que ha sido modelado según los sistemas de journaling de Ext3/4 y reiserfs. Permite acumular múltiples transacciones asíncronas en memoria. La reducción del ancho de banda utilizado para el log decrece en gran medida, y las cargas que hacen un uso intensivo de los metadatos aumentan su rendimiento en la misma proporción. El formato de disco del journal no ha cambiado, solo las estructuras en memoria y el código. Esta característica es aun experimental, asi que no está recomendada excepto para pruebas. Puede activarse con la opción "-o delaylog"
· Frontend del depurador KDB: Linux ha tenido un depurador desde 2.6.26, llamado Kgdb. Pero desde hace años existen dos depuradores para Linux, Kgdb y KDB. La diferencia entre ambos siempre fue que Kgdb requiere un ordenador adicional en el que ejecutar una instancia de gdb, que permite una depuración profunda. KDB, en cambio, puede utilizarse en el mismo ordenador, pero sus características de depurado son más simples. En esta versión se ha incluido también el depurador KDB, pero modificado para funcionar sobre los mecanismos internos de KGDB.
· Mejoras de perf:
- Modo "live" perf-inject: Hasta ahora, los usuarios tenían que ejecutar "perf record" y "perf report" en dos comandos diferentes. Perf-inject introduce un modo "live", que permite grabar y reportar en un solo comando, como por ejemplo perf record -o - ./hackbench 10 | perf inject -v -b | perf report -v -i - . Pero esto es demasiado complejo, asi que se ha añadido soporte para invocar automáticamente el modo live si no se especifica record/report. Por ejemplo: perf trace rwtop 5. Cualquiera de los scripts listados en 'perf trace -l' pueden utilizarse directamente el modo live.
- perf kvm: Una herramienta para monitorizar el rendimiento de las VMs desde el host.
- perf probe: Soporte para acceder a miembros de las estructuras de datos. Con est, perf-probe acepta miembros de estructuras (es decir, acepta los operadores punto '.' y flecha '->') como argumentos. Ejemplos: # perf probe --add 'schedule:44 rq->curr'. O # perf probe --add 'vfs_read file->f_op->read file->f_path.dentry'
- Mejorar --list: para mostrar las sondas existentes con número de línea y nombre de archivo. Esto permite comprobar fácilmente qué linea está "sondeada". Por ejemplo:
· Mejoras gráficas: i915: Soporte de aceleración para vídeo H.264 y VC1 en hardware G45+, soporte del futuro Intel Cougarpoint, monitorización de energía y autorefresco de memoria en hardware Ironlake. Radeon: Trabajo inicial para la gestión de energía, simplificación y mejora del reseteo de GPU, implementación varias partes importantes para soportar chips Evergreen, permitir el uso de VRAM no mapeable, soporta para cuando no hay salidas de vídeo conectadas.
· Compactación de memoria: Este es un mecanismo que trata de reducir la fragmentación externa de la memoria que intenta agrupar las páginas utilizadas y las libres en un gran bloque de páginas usadas y un gran bloque de páginas libres, lo que permite hacer asignaciones de memoria grandes que no son posibles si hay fragmentación. La implementación consiste en dos escanners, uno de páginas a migrar, que empieza a buscar páginas utilizadas por el principio de la zona de memoria, y otro de páginas libres, que empieza a buscar páginas libres por el final. Cuando ambos escanners se encuentran en el medio de la zona, se mueven las páginas utilizadas al lugar de las libres. Las pruebas han mostrado que la cantidad de I/O requerido para satisfacer una gran asignación disminuye drásticamente. La compactación puede activarse de tres modos diferentes: manualmente, escribiendo algún valor a /proc/sys/vm/compact_memory. Puede activarse manualmente, pero para una sola zona determinada, escribiendo algún valor a /sys/devices/system/node/nodeN/compact. Y también se activa automáticamente cuando no se consigue asignar una gran porción de memoria.
· Soporte para múltiples tablas de ruta multicast: normalmente, un router multicast ejecuta un demonio en espacio de usuario que decide con un paquete fijándose en las direcciones de origen y destino. Esta característica añade soporte para múltiples tablas de rutas multicast, así el kernel es capaz de tomar las interfaces y las marcas de los paquetes y ejecutar múltiples demonios en espacio de usuario simultaneamente, cada uno manejando una sola tabla.
· Soporte de L2TP versión 3 (RFC 3931): Esta versión añade soporte para Layer 2 Tunneling Protocol (L2TP) version 3, RFC 3931.
· Protocolo CAIF: Se trata de un protocolo utilizado por módems ST-Ericsson.
· ACPI Platform Error Interface: Soporte para la ACPI Platform Error Interface (APEI). Este sistema mejora especialmente la gestión de NMI (interrupciones no enmascarables). Además, soporta una tabla para guardar errores MCE en flash.
Esto viene a ser todo. Como siempre, aquí está la lista completa.
· Reparto automático entre varias CPUs del tráfico de red de entrada: Las tarjetas de red actuales han mejorado su rendimiento hasta el punto de que para una sola CPU moderna es cada vez más difícil mantener el ancho de banda de recepción al máximo. Dos nuevas características, contribuidas por Google, ayudan a repartir automáticamente la carga de los paquetes de red entrantes entre varias CPUs (los salientes ya se reparten por si solos). El procesado de protocolos(IP, TCP) se ha modificado para que pueda hacerse en paralelo. Cada dispositivo de red utiliza diferentes heurísticas para decidir en qué CPU se procesará el paquete (hash de la cabecera del paquete, afinidad con la CPU en la que se está ejecutando la aplicación que lo va a recibir). Esta característica emula por software lo que una tarjeta de red multiqueue hace en hardware. Un benchmark de 500 instancias del test netperf TCP_RR con 1 byte de petición y respuesta en una e1000e montada en un servidor con CPU Intel de 8 cores ascienden de 104K tps a 303K tps. Un test RPC con 100 threads en cada host, va de 103K tps a 223K, y con menos latencia.
· Mejoras Btrfs: Direct I/O y -ENOSPC completo. Direct I/O es una técnica utilizada para saltarse el caché a la hora de escribir. Esto daña el rendimiento (es como montar un sistema de archivos en modo "sync"), pero es utilizado extensivamente en grandes bases de datos a las que les gusta implementar su propio cache optimizado. -ENOSPC completo: Linux 2.6.32 ya tenía soporte de -ENOSPC para el uso común del sistema de archivos, pero existían varios casos raros en ciertas operaciones complejas, como operaciones de gestión de volumenes, en los que podía haber fallos. El código -ENOSPC de esta versión maneja correctamente todos los casos: balanceo de espacio libre, gestión de discos, logging de fsync y otros.
· XFS delayed logging: Esta versión añade un nuevo modo de journaling para XFS llamado "delayed logging", que ha sido modelado según los sistemas de journaling de Ext3/4 y reiserfs. Permite acumular múltiples transacciones asíncronas en memoria. La reducción del ancho de banda utilizado para el log decrece en gran medida, y las cargas que hacen un uso intensivo de los metadatos aumentan su rendimiento en la misma proporción. El formato de disco del journal no ha cambiado, solo las estructuras en memoria y el código. Esta característica es aun experimental, asi que no está recomendada excepto para pruebas. Puede activarse con la opción "-o delaylog"
· Frontend del depurador KDB: Linux ha tenido un depurador desde 2.6.26, llamado Kgdb. Pero desde hace años existen dos depuradores para Linux, Kgdb y KDB. La diferencia entre ambos siempre fue que Kgdb requiere un ordenador adicional en el que ejecutar una instancia de gdb, que permite una depuración profunda. KDB, en cambio, puede utilizarse en el mismo ordenador, pero sus características de depurado son más simples. En esta versión se ha incluido también el depurador KDB, pero modificado para funcionar sobre los mecanismos internos de KGDB.
· Mejoras de perf:
- Modo "live" perf-inject: Hasta ahora, los usuarios tenían que ejecutar "perf record" y "perf report" en dos comandos diferentes. Perf-inject introduce un modo "live", que permite grabar y reportar en un solo comando, como por ejemplo perf record -o - ./hackbench 10 | perf inject -v -b | perf report -v -i - . Pero esto es demasiado complejo, asi que se ha añadido soporte para invocar automáticamente el modo live si no se especifica record/report. Por ejemplo: perf trace rwtop 5. Cualquiera de los scripts listados en 'perf trace -l' pueden utilizarse directamente el modo live.
- perf kvm: Una herramienta para monitorizar el rendimiento de las VMs desde el host.
- perf probe: Soporte para acceder a miembros de las estructuras de datos. Con est, perf-probe acepta miembros de estructuras (es decir, acepta los operadores punto '.' y flecha '->') como argumentos. Ejemplos: # perf probe --add 'schedule:44 rq->curr'. O # perf probe --add 'vfs_read file->f_op->read file->f_path.dentry'
- Mejorar --list: para mostrar las sondas existentes con número de línea y nombre de archivo. Esto permite comprobar fácilmente qué linea está "sondeada". Por ejemplo:
# perf probe --list
probe:vfs_read (on vfs_read:8@linux-2.6-tip/fs/read_write.c)
- Implementación de una UI en la consola con newt.· Mejoras gráficas: i915: Soporte de aceleración para vídeo H.264 y VC1 en hardware G45+, soporte del futuro Intel Cougarpoint, monitorización de energía y autorefresco de memoria en hardware Ironlake. Radeon: Trabajo inicial para la gestión de energía, simplificación y mejora del reseteo de GPU, implementación varias partes importantes para soportar chips Evergreen, permitir el uso de VRAM no mapeable, soporta para cuando no hay salidas de vídeo conectadas.
· Compactación de memoria: Este es un mecanismo que trata de reducir la fragmentación externa de la memoria que intenta agrupar las páginas utilizadas y las libres en un gran bloque de páginas usadas y un gran bloque de páginas libres, lo que permite hacer asignaciones de memoria grandes que no son posibles si hay fragmentación. La implementación consiste en dos escanners, uno de páginas a migrar, que empieza a buscar páginas utilizadas por el principio de la zona de memoria, y otro de páginas libres, que empieza a buscar páginas libres por el final. Cuando ambos escanners se encuentran en el medio de la zona, se mueven las páginas utilizadas al lugar de las libres. Las pruebas han mostrado que la cantidad de I/O requerido para satisfacer una gran asignación disminuye drásticamente. La compactación puede activarse de tres modos diferentes: manualmente, escribiendo algún valor a /proc/sys/vm/compact_memory. Puede activarse manualmente, pero para una sola zona determinada, escribiendo algún valor a /sys/devices/system/node/nodeN/compact. Y también se activa automáticamente cuando no se consigue asignar una gran porción de memoria.
· Soporte para múltiples tablas de ruta multicast: normalmente, un router multicast ejecuta un demonio en espacio de usuario que decide con un paquete fijándose en las direcciones de origen y destino. Esta característica añade soporte para múltiples tablas de rutas multicast, así el kernel es capaz de tomar las interfaces y las marcas de los paquetes y ejecutar múltiples demonios en espacio de usuario simultaneamente, cada uno manejando una sola tabla.
· Soporte de L2TP versión 3 (RFC 3931): Esta versión añade soporte para Layer 2 Tunneling Protocol (L2TP) version 3, RFC 3931.
· Protocolo CAIF: Se trata de un protocolo utilizado por módems ST-Ericsson.
· ACPI Platform Error Interface: Soporte para la ACPI Platform Error Interface (APEI). Este sistema mejora especialmente la gestión de NMI (interrupciones no enmascarables). Además, soporta una tabla para guardar errores MCE en flash.
Esto viene a ser todo. Como siempre, aquí está la lista completa.
Suscribirse a:
Entradas (Atom)