Las novedades de Linux 3.13

Ya se ha anunciado la versión 3.13 de Linux. Entre las novedades de esta versión destacan nftables, el sucesor de iptables, un rediseño de la capa de bloques optimizado para SSDs de alto rendimiento, un framework para establecer límites de consumo energético en dispositivos Intel RAPL, mejora del rendimiento de squashfs, gestión energética en dispositivos AMD Radeon activada por defecto, mejor rendimiento en sistemas NUMA, mejor rendimiento en cargas donde se utilicen "hugepages", TCP Fast Open activado por defecto, soporte para pagos NFC y soporte para el protocolo High-availability Seamless Redundancy. 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.


· Capa de bloques escalable, diseñada para dispositivos SSD de alto rendimiento
Durante décadas, los discos duros tradicionales han determinado el diseño de las partes de los sistemas operativos que comunican a las aplicaciones con los dispositivos de almacenamiento. Con las nuevas generaciones de discos de estado sólido, SSD, esos requisitos antiguos ya no tienen validez. La capa de bloques de Linux estaba diseñada con un sólo bloqueo que protegía la cola de peticiones de ES, este diseño puede conseguir un ratio de 800.000 operaciones de ES por segundo, al margen de cuántos cores se utilizasen para hacer ES. Esto era más que suficiente para los discos magnéticos tradicionales, cuyo ratio en accesos aleatorios no pasa de varios cientos de ES/s, pero no es suficiente para los discos SSD más modernos, que alcanzan un ratio de 1 millón, y mejoran con rapidez en cada nueva generación. Tampoco es un diseño apropiado para el mundo multicore actual.

Esta versión incluye un rediseño de la capa de bloques de Linux, que pasa a estar basada en dos niveles de colas: Un nivel de colas por-cada-CPU para enviar ES, que posteriormente pasan a un segundo nivel de colas de envío hacia el hardware. El mapeado entre las colas de envío y las colas de hardware puede ser 1:1 o M:N, dependiendo del hardware y la configuración. La experimentación ha demostrado que este diseño puede alcanzar varios millones de operaciones ES/s, pudiendo de este modo aprovechar las nuevas capacidades de los dispositivos SSD NVM-Express o PCI-E, y también las CPUs multicore, al mismo tiempo que se mantienen la interfaz y ventajas de una capa de bloques.

· nftables, el sucesor de iptables
iptables tiene una serie de limitaciones tanto a nivel funcional como de diseño: problemas con la actualización de reglas o duplicación de código, que causan problemas al mantenimiento del código y a los usuarios. nftables es un nuevo sistema de filtrado de paquetes que resuelve esos problemas, manteniendo al mismo tiempo compatibilidad para los usuarios de iptables.

El núcleo del diseño de nftables es una pseudo-máquina virtual simple inspirada en BPF. Una nueva utilidad interpreta las reglas proporcionadas por el usuario, las compila a un pseudo-bytecode y transfiere el resultado al kernel. Este sistema puede reemplazar miles de líneas de código, ya que el conjunto de instrucciones del bytecode permite expresar los selectores de paquetes para todos los protocolos. Dado que la utilidad en espacio de usuario interpreta los protocolos y los traduce a ese bytecode, ya no es necesario incorporar en el kernel extensiones específicas para nuevos protocolos, lo cual significa que los usuarios no tendrán que actualizar el kernel para conseguir soporte para nuevos protocolos y matches, sólo será necesario actualizar la utilidad. Hay también una nueva librería para las utilidades que necesiten interactuar con el cortafuegos.

nftables proporciona compatibilidad con iptables. Hay nuevas utilidades iptables/iptables que traducen reglas de iptables al nuevo bytecode, y es posible también usar e introducir nuevos módulos xtables. Como bonus, estas nuevas utilidades proporcionan características que eran imposibles con el antiguo diseño: notificaciones para cambios en las tablas y cadenas, mejor soporte para actualizaciones incrementales de reglas, y la habilidad para activar/desactivar cadenas de cada tabla. Hay un una pequeña guía de la nueva utilidad y su sintaxis aquí. Página del poyecto: http://netfilter.org/projects/nftables/


· Radeon: soporte de gestión energética activado por defecto, cambio automático de GPU, soporte de Radeon R9 290X 'Hawaii'
 · Gestión energética activada por defecto: Linux 3.11 añadió soporte de gestión energética para dispositivos AMD Radeon. La gestión energética mejora el consumo energético, que es crítico para los dispositivos alimentados por baterías, pero es también un requisito para conseguir alto rendimiento, ya que permite reprogramar la velocidad de reloj a estados más potentes en algunas GPUs y APUs que se inician por defecto en estados menos potentes.

Este soporte tenía que activarse con un parámetro en el módulo. En esta versión, la gestión energética está activada por defecto para buena parte del hardware AMD Radeon: BTC asics, SI asics, SUMO/PALM APUs, evergreen asics, r7xx asics y hawaii.

 · Cambio automático de GPU: El soporte para cambio automático de GPUs se introdujo en Linux 3.12. Esta versión añade soporte para esta característica en hardware AMD Radeon.

 · Soporte de R9290X 'Hawaii': Esta versión añade soporte para los dispositivos R9 290X "Hawaii"

· Framework para la limitación de consumo energética
Esta versión añade un framework que permite configurar límites de consumo de energía en los dispositivos que soporten esa funcionalidad. Ha sido diseñado pensando en el mecanismo Intel RAPL (Running Average Power Limit), disponible en los últimos procesadores de Intel (Sandy Bridge y posteriores, otros muchos dispositivos añadirán soporte posteriormente). Este framework proporciona una interfaz consistente entre el kernel y el espacio de usuario para exponer sus mecanismos de configuración con uniformidad.

· Soporte para la arquitectura Intel Many Integrated Core
Esta versión añade soporte para la arquitectura Intel Many Integrated Core o MIC, una arquitectura que incorpora parte del trabajo realizado anteriormente en la arquitectura Larrabee, el proyecto Teraflops Research Chip, y el procesadorIntel Single-chip Cloud Computer. El superordenador más potente del mundo, el Tianhe-2 del Centro Nacional de Supercomputación en Guangzhou, China, utiliza esta arquitectura para conseguir 33.86 PetaFLOPS.

La familia MIC de coprocesadores en formato PCIe ejecuta un sistema operativo Linux de 64 bits. El driver gestiona el estado del sistema operativo en la tarjeta y establece comunicación entre el equipo y la tarjeta. Más información sobre la familia de dispositivos Intel Mic y sobre el sistema operativo y herramientas para MIC están disponibles aquí. Esta versión soporta los dispositivos Intel MIC X100, e incluye un demonio en espacio de usuario de ejemplo.

· Mejora del rendimiento en sistemas NUMA
Los sistemas multiprocesador modernos (ejemplo, x86) suelen tener sistemas de memoria NUMA ("non-uniform memory access"). En estos sistemas, el rendimiento de un proceso puede ser diferente dependiendo de si el rango de memoria al que accede está conectado a la CPU local o a otra CPU. Dado que el rendimiento depende de la localidad de los accesos a la memoria, es importante que el sistema operativo programe un proceso para que se ejecute en la misma CPU donde está conectada la memoria a la que accederá.

La manera que Linux tenía de tratar estas situaciones era deficiente. En Linux 3.8 se incluyó una nueva fundación para el soporte de NUMA que permitiría añadir políticas NUMA más inteligentes en el futuro. Esta versión incluye varias de esas políticas, y puede gestionar casos tales como los de procesos que comparten páginas de memoria, o los que utilizan hugepages transparentes. Se han añadido nuevas sysctls para activar o desactivar y configurar este soporte (ver documentación aquí).

· Mejora de la escalabilidad del acceso a la tabla de páginas en cargas con hugepage
Linux mantiene información sobre cada página de memoria en una estructura de datos llamada tabla de páginas. En las situaciones en que se utilizan hugepages, el bloqueo utilizado para proteger algunas partes de la tabla se ha convertido en un punto de contención. Esta versión incluye bloqueos más eficientes para esas partes de la estructura, mejorando la escalabilidad del acceso a la tabla de páginas en las cargas con hugepage y muchos procesos.

· Mejora del rendimiento de squashfs
Squashfs, el sistema de sólo lectura utilizado por la mayoría de distribuciones live, instaladores y algunas distros embebidas, ha incorporado mejoras que aumentan notablemente el rendimiento en cargas donde estén envueltas varias lecturas paralelas. Uno de ellas es la descompresión directa de los datos en el caché de páginas, lo cual evita una copia de los datos y elimina el bloqueo utilizado para proteger al búfer intermedio. El otro es el soporte de la descompresión multihilo.

· TCP Fast Open activado por defecto
TCP Fast Open es una optimización del proceso de establecimiento una conexión TCP que permite eliminar un viaje de ida y vuelta de ciertos tipos de conversaciones TCP, lo cual puede mejorar el tiempo de carga de páginas web. En Linux 3.6 y Linux 3.7 se añadió soporte para esta característica, que requiere soporte de espacio de usuario. En esta versión, el soporte de TCP Fast Open está activado por defecto.

· Soporte de pagos NFC
Esta versión añade soporte para el Secure Element. Una API netlink permite activar, desactivar y descubrir los elementos seguros NFC. Con ayuda de espacio de usuario, esto permite soportar pagos NFC, que son útiles para implementar transacciones financieras. Sólo el driver pn544 soporta esta API de momento.

· Soporte para el protocolo High-Availability Seamless Redundancy
El protocolo High-availability Seamless Redundancy (HSR) es un protocolo de redundancia para Ethernet. Proporcional redundancia y tolerancia a fallos para dichas redes. Requiere una topología de red especial donde todos los nodos estén conectados a un anillo (y cada nodo tenga dos interfaces de red físicas). Está orientado a aplicaciones que requieren alta disponibilidad y tiempo de reacción muy corto.

Y eso es todo. La lista completa de cambios en inglés, aquí.

CentOS se une a Red Hat, se cierra el círculo

El proyecto CentOS, consistente en quitar el copyright y algunas utilidades propietarias de RHEL, ha decidido integrarse con Red Hat. Red Hat se queda con la marca "CentOS", contrata a varios de sus desarrolladores, les proporciona recursos para mantener la distribución, pero sin modificar la esencia de la distro en si.

Como señalaban en Hacker News, esta decisión supone para Red Hat una curiosa trayectoria circular. En un principio la distribución Red Hat estaba disponible para la libre descarga, y la compañía Red Hat ofrecía soporte. Un día decidieron que la distribución de marca Red Hat ya no sería de libre distribución, y formaron RHEL, de pago, y por otro lado iniciaron Fedora, una distribución libre. Pero CentOS empezó a ofrecer una versión de RHEL sin la marca Red Hat. Y ahora Red Hat une fuerzas con CentOS, garantizando una versión libre, sin soporte, de Red Hat, aunque sea sin la marca.

Es decir, la situación vuelve a estar más o menos como al principio.

Podría decirse, supongo, que con esta decisión Red Hat está reconociendo implícitamente errores en el pasado, aunque habría que tener en cuenta que cada paso en la evolución de Red Hat ha respondido a diferentes momentos en los que tuvo diferentes necesidades, y todas ellas podrían ser perfectamente lógicas rodeadas de sus circunstancias. Pero, ¿a qué circunstancias responde la unión con CentOS? ¿Por qué CentOS es más útil a Red Hat hoy de lo que lo era hace años?

Hay una razón inmediata que a todos se nos ocurre, y es que existe una ingente demanda de distribuciones Linux "serias", estables, con buen mantenimiento y, sobre todo, gratuitas. Red Hat sabe que es inútil intentar hacer pagar a esa demanda un sólo dólar, por lo tanto no tiene, como empresa, un interés directo en ella. Sin embargo, si puede tener interés en evitar que otras distribuciones aprovechen esa demanda para hacerse un hueco e introducir sus propias ofertas de soporte comercial. Un competidor en este sentido podemos verla en esta estadística de distribuciones Linux en servidores web (de fiabilidad limitada), donde se ve como Ubuntu Server está encumbrándose rápidamente y convirtiéndose en la opción por defecto de mucha gente. Otra versión comercial de estos competidores, más serio, es Oracle Linux.

Sin embargo, y aunque estas razones puedan existir, parece más creíble la versión que Red Hat ha ofrecido, que parece centrarse especialmente en la facilidad que ofrecería a partir de ahora CentOS para crear variantes de CentOS, y muy especialmente variantes centradas en OpenStack, la plataforma para la creación de nubes apoyada por Red Hat:

Red Hat’s success begins with community-powered innovation. For instance, growth of OpenStack and of RDO leads to growing code maturity and mindshare for the project and for Red Hat and, in turn, more demand for Red Hat Enterprise Linux OpenStack Platform subscriptions.

Red Hat is taking an active role in the CentOS Project to accelerate the development and broaden the reach of projects such as OpenStack by expanding our base of community-oriented users to include those engaged with CentOS now and in the future.

By working with the CentOS Project, we can reach beyond those actively engaged in platform innovation through Fedora to projects and people in need of a community Linux distribution that’s open to selective modification while remaining relatively stable.

Parece una descripción bastante sincera de sus intenciones; sin embargo, cabe destacar que en toda esta historia hay un perdedor, que a mi juicio es Fedora. Fedora ha tenido éxito como centro de innovación y desarrollo para Red Hat y como distro para aquellos a quienes les interese estar a la última, pero ha perdido fuerza como distribución generalista para el gran público, tanto de escritorio como de servidores. En teoría, Red Hat podría haber ofrecido OpenStack dentro de Fedora, como un spin de Fedora...de hecho, podría haber intentado competir con CentOS como distribución Redhatera estable, con versiones LTS con buena política de soporte de actualizaciones, pero no se ha preocupado demasiado por ello (quizás precisamente porque para eso ya estaba CentOS).

Será interesante comprobar si esto afecta a Fedora, y si alguno de los spins de Fedora se pasa a CentOS, o si incluso Fedora y CentOS acaban uniendo fuerzas a largo plazo.