tag:blogger.com,1999:blog-79745222024-03-29T12:03:44.327+01:00D'Oh!Diegohttp://www.blogger.com/profile/18081775339476161685noreply@blogger.comBlogger942125tag:blogger.com,1999:blog-7974522.post-32910447099310564342020-10-14T00:22:00.001+02:002020-10-14T00:22:44.287+02:00Las novedades de Linux 5.9<div><p>Ya <a href="https://lore.kernel.org/lkml/CAHk-=wi-u86++np80GQvgDuARdt9xpBNho6SjHLmYgm8jibGag@mail.gmail.com/T/#u">se ha publicado</a> la versión 5.9 de Linux. Esta versión incorpora una mejor gestión de la memoria anónima (malloc); un nuevo controlador de memoria slab que permite compartir esa memoria entre diferentes cgroups; soporte para defragmentación de memoria proactiva; conocimiento de las capacidades de la CPU por la clase de planificación deadline; soporte para ejecutar programas BPF cuando se accede a un socket; nueva llamada al sistema close_range() para cerrar rangos enteros de descriptores de archivos; soporte para las instrucciones x86 FGFSBASE que permiten un cambio de contexto más veloz; soporte de atributos extendidos en NFS; y soporte para kernels, discos ram e initrds comprimidos con ZSTD. Además, hay muchas otras mejoras y pequeños parches. La lista
completa de cambios, en inglés, se encuentra <a href="https://kernelnewbies.org/Linux_5.9">aquí</a>.<br /><br /></p><ul style="text-align: left;"><li> <b>Mejor gestión de la memoria anónima <br /></b></li></ul><div style="margin-left: 40px; text-align: left;">Esta versión implementa mejor detección y protección de memoria anónima (memoria que no está respaldada por archivos, como por ejemplo la proveniente de malloc). Linux gestiona la memoria anónima ubicando sus páginas en la lista activa o inactiva. Cuando hay presión de memoria, las páginas menos utilizadas se mueven de la lista activa a la inactiva y desmapeadas, dándoles la oportunidad de ser referenciadas de nuevo (lo que se llama una falta ligera) antes de ser trasladadas al intercambio, si hay más presión.</div><div style="margin-left: 40px; text-align: left;"><br /></div><div style="margin-left: 40px; text-align: left;">En la implementación previa, las páginas recién creadas o traídas del intercambio se ubicaban en la lista activa, lo cual podía forzar a reubicar las que estaba siendo utilizadas activamente a la lista inactiva. En esta versión, las páginas nuevas o traídas del intercambio se ubican en la lista inactiva, y sólo son ascendidas a la lista activa si son referenciadas lo suficiente. Adicionalmente, y porque este cambio puede provocar que esas páginas hagan descender a las páginas inactivas al intercambio, se ha extendido el mecanismo de detección de carga de trabajo ya existente para que gestione también la lista de memoria anónima, para así tomar mejores decisiones.<br /></div></div><ul style="text-align: left;"><li><b>Nuevo controlador de slab de cgroups que es capaz de compartir memoria</b></li></ul><div style="margin-left: 40px; text-align: left;">El controlador de memoria slab se basó en la idea de replicar un asignador de memoria slab en cada cgroup, lo cual tuvo como consecuencia que esos cgroups no compartiesen memoria slab entre ellos, algo que provoca baja utilización del slab y mayor uso de memoria. El controlador de slab solía ser algo opcional, pero hoy se activa por defecto en el controlador de memoria, y los sistemas modernos con systemd crean muchos cgroups, por lo que este problema afecta a mucha gente.</div><div style="margin-left: 40px; text-align: left;"><br /></div><div style="margin-left: 40px; text-align: left;">Esta versión incorpora una nueva implementación de controlador de slab que permite compartir memoria entre cgroups. En pruebas de Facebook, este sistema ahorra entre varios cientos de MB hasta 1 GB por equipo; de media el tamaño de la memoria de slabs se redujo un 35-45%. Los escritorios también se benefician: en un sistema Fedora de 16 GB, el nuevo controlador ahorra un 45-50% de memoria slab, medido justo tras iniciar el sistema.</div><div style="text-align: left;"><br /></div><div><div><ul style="text-align: left;"><li><b>Compactación de memoria proactiva</b><br /></li></ul><div style="margin-left: 40px; text-align: left;">Las páginas gigantes (páginas mayores de 4KB en x86) son una característica de los procesadores que puede mejorar el rendimiento debido a la reducción del uso del TBL. Hacer uso de esas páginas requiere tener grandes cantidades de memoria vacía contigua, lo cual puede resultar difícil si la memoria está fragmentada. Linux soporta la compactación (es decir, defragmentación) de memoria, pero sólo entra en funcionamiento cuando se necesita asignar una nueva página de memoria, lo cual puede tomar tiempo y dañar la latencia de la asignación. Esta versión añade soporte para la compactación de memoria proactiva, es decir, el mecanismo empieza a funcionar antes de hacer ninguna asignación, de manera que futuras asignaciones puedan finalizar con mayor velocidad.<br /></div><p style="text-align: left;"> </p><ul style="text-align: left;"><li><b>Nueva llamada al sistema close_range() para cerrar descriptores de archivos más fácilmente</b> <br /></li></ul><div style="margin-left: 40px; text-align: left;">Esta versión incorpora una nueva llamada al sistema, close_range(2). Permite cerrar con eficiencia un rango de descriptores de archivos de una tarea. Por ejemplo, close_range(3, ~0U) cierra todos los descriptores de archivo más allá de stderr. Resulta que hay muchos proyectos que necesitan hacer exactamente eso: gestores de servicios, libcs, gestores de contenedores, lenguajes de programación/librerías estándar (Rust/Python). Esta llamada al sistema ha sido coordinada con FreeBSD, de modo que también está disponible allí.<br /></div><p style="text-align: left;"><br /></p><ul style="text-align: left;"><li><b>Soporte para ejecutar programas BPF cuando se accede a un socket</b><br /></li></ul><p style="text-align: left;"></p><p style="margin-left: 40px; text-align: left;">Como en cada nueva versión, hay muchas mejoras en BPF. Una característica interesante es un nuevo tipo de programa BPF llamado BPF_PROG_TYPE_SK_LOOKUP, que se ejecuta cuando la capa de transporte está intentando conectar con socket para establecer una nueva conexión TCP, o cuando se intenta enviar datos a un socket UDP. Este mecanismo sirve para superar las limitaciones de bind(). Hay dos casos de uso que motivan este trabajo: 1) reconducir paquetes destinados a un rango IP determinado, de un puerto a un socket, 2) reconducir paquetes destinados a una dirección IP, de cualquier puerto a un socket.<br /></p></div><div></div><div></div><div><p style="text-align: left;"> </p><ul style="text-align: left;"><li><b>Conocimiento de las capacidades de la CPU por la clase de planificación deadline</b></li></ul><p googl="true" style="margin-left: 40px; text-align: left;"> Desde Linux 3.14, el planificador de tareas de Linux soporte una <a href="https://www.kernel.org/doc/html/latest/scheduler/sched-deadline.html">clase de planificación deadline</a>, diseñada con conceptos de tiempo real para aplicaciones que tienen requerimientos de tiempos muy estrictos. Esta clase de planificación no tiene noción de la existencia de plataformas con CPUs heterogeneas donde las CPUs no tienen el mismo rendimiento (por ejemplo, ARM big.LITTLE), lo cual lleva a tomar decisiones equivocadas. Esta versión hace que la clase de planificación deadline esté al tanto de la capacidad de cada CPU.<br /></p><p style="text-align: left;"> </p><p style="text-align: left;"></p><p style="text-align: left;"> </p><ul style="text-align: left;"><li><b>Cambio de contexto más rápido con las instrucciones de x86 FGFSBASE</b> <br /></li></ul><div style="margin-left: 40px; text-align: left;">Las instrucciones FGFSBASE son una característica de Intel disponible desde hace tiempo. Permiten el acceso directo a los registros de segmento FG y FS. Además de los beneficiones para las aplicaciones, hay mejoras de rendimiento en el cambio de contexto.<br /></div><p style="text-align: left;"> </p><ul style="text-align: left;"><li><b>Soporte en NFS de atributos extendidos</b> <br /></li></ul><div style="margin-left: 40px; text-align: left;">Esta versión incorpora el soporte en NFS para atributos extendidos (<a href="https://tools.ietf.org/html/rfc8276">RFC 8276</a>), lo cual resuelve una de las carencias más importantes de NFS.</div><div style="margin-left: 40px; text-align: left;"> </div><p style="text-align: left;"></p><ul style="text-align: left;"><li> <b>Soporte para kernel, ramdisk e initramfs comprimidos con ZSTD</b><br /></li></ul><p style="margin-left: 40px; text-align: left;">Esta versión incorpora soporte para un kernel, ramdisk e initrd comprimidos con ZSTD. ZSTD ofrece buenas capacidades de compresión, y magníficas velocidades de descompresión. En pruebas de Facebook, cambiar de initrd comprimido con xz a ZSTD redujo el tiempo de descompresión de 12 segundos a 3 segundos. Cuando cambiaron el kernel, ahorraron 2 segundos en el tiempo de arranque.<br /></p><p style="text-align: left;"><br /></p><p style="text-align: left;"></p><p style="text-align: left;">Y eso es todo. Como siempre, pueden encontrar la lista completa de cambios, en inglés, en <a googl="true" href="https://kernelnewbies.org/Linux_5.9">esta página</a>.<br /></p></div></div>Diegohttp://www.blogger.com/profile/18081775339476161685noreply@blogger.com1tag:blogger.com,1999:blog-7974522.post-10683750722714921802020-06-01T21:03:00.001+02:002020-06-01T21:06:08.304+02:00Las novedades de Linux 5.7<div>Ya se ha <a href="https://lore.kernel.org/lkml/CAHk-=wiZGrCkiBB1V7bxp8NZH6yWi9mPM4ptMW16OzOiNprBFA@mail.gmail.com/">publicado Linux 5.7</a>.
Las novedades de esta versión son: Soporte de Presión Termal, que permite que el organizador de tareas tome mejores decisiones en presencia de cambios de frecuencia de CPU; soporte para contabilidad del organizador de frecuencia invariante, que logra que x86 funciona con más rendimiento con el gobernador cpufreq schedutil; una nueva y mejor implementación del sistema de archivos exFAT; soporte para una característica de x86 que permite detectar operaciones atómicas que abarcan varias líneas cache; soporte de Autentificación de Punteros de ARM en el código del kernel, que frena algunos problemas de seguridad; soporte para engendrar procesos con clone() dentro de un cgroup determinado; soporte de protección para escritura en userfaultfd(), que es equivalente (pero más rápido) que usar mprotect(2) y señales SIGSEGV; y un Módulo de Seguridad Linux basado en BPF que permite una auditoría de seguridad más dinámica. Además, hay muchas otras mejoras y pequeños parches. La lista
completa de cambios, en inglés, se encuentra <a href="https://kernelnewbies.org/Linux_5.7">aquí</a>.</div>
<br /><ul style="text-align: left;"><li>El organizador de tareas incorpora el concepto de <b>Presión Termal</b></li></ul><div style="margin-left: 40px; text-align: left;">Cuando una CPU se calienta en exceso, el gobernador termal procede a limitar su frecuencia máxima. Esta limitación reduce, sin embargo, la capacidad de computación de esa CPU. Si el organizador de tareas no está al tanto de esos cambios de frecuencia, tomará decisiones equivocadas, asumiendo que la CPU tiene más capacidad de computación de la que realmente tiene en ese momento.</div><div style="margin-left: 40px; text-align: left;"><br /></div><div style="margin-left: 40px; text-align: left;">Esta versión incorpora el concepto de Presión Termal, que logra que el organizador de tareas esté más al corriente de los cambios de frecuencia, y por tanto, que tome mejores decisiones cuando los sistemas están calentándose en exceso, lo cual mejora el rendimiento. Artículo LWN recomendado: <a href="https://lwn.net/Articles/788380/">Telling the scheduler about thermal pressure</a></div><div><br /></div><div><ul style="text-align: left;"><li> Contabilidad del organizador de frecuencia invariante en x86.</li></ul><div style="margin-left: 40px; text-align: left;">Supongamos que una CPU tiene dos frecuencias: 500 y 1000 MHz. Cuando ejecuta una tarea que normalmente consumiría 1/3 de la CPU a 1000 MHz, aparentaría consumir 2/3 si la CPU funcionase a 500 MHz, dando la falsa impresión de que la CPU está casi al máximo de su capacidad, a pesar de que puede ir más rápido. Sin una escala de frecuencia invariante, las tareas parecen más grandes sólo porque la CPU funciona con más lentitud. El gobernador de cpufreq schedutil -que utiliza información de utilización proporcionada por el organizador de procesos para tomar sus decisiones- toma decisiones equivocadas y tiene peor rendimiento.</div><div style="margin-left: 40px; text-align: left;"><br /></div><div style="margin-left: 40px; text-align: left;">Esta versión incorpora una implementación de contabilidad del organizador con frecuencia invariante en algunas CPUs x86. Esto hace que las estimaciones de capacidad sean más precisas y las tareas permanezcan en la misma CPU en presencia de cambios de voltaje y frecuencia. Las mejoras introducidas han dado motivo para que el driver intel_pstate utilice por defecto el gobernador schedutil. Artículo de LWN recomendado: <a href="https://lwn.net/Articles/816388/">Frequency-invariant utilization tracking for x86</a>.</div><div style="margin-left: 40px; text-align: left;"><br /></div><div style="text-align: left;"><ul style="text-align: left;"><li>Nuevo sistema de archivos exFAT</li></ul><div style="margin-left: 40px; text-align: left;">Linux 5.4 añadió una implementación experimental del sistema de archivos exFAT. Este sistema de archivos ha sido eliminado; en su lugar, se ha decidido que una implementación alternativa creada por Samsung tenía mayor calidad, y ha sido añadida en esta versión.<br /></div><div style="text-align: left;"><br /></div><div style="text-align: left;"><ul style="text-align: left;"><li>Detección de bloqueos partidos</li></ul><div style="margin-left: 40px; text-align: left;">Un bloqueo partido sucede cuando una instrucción de CPU atómica opera sobre datos que abarcan más de una línea cache. Es mucho más lento que una operación atómica que opera en una sola línea cache, y además empeora el rendimiento en otros procesadores. Esta versión incorpora una característica de x86 que permite detectar bloqueos partidos. Utilizando la opción de arranque split_lock_detect, es posible advertir o incluso enviar la señal SIGBUS a las aplicaciones que hacen uso de bloqueos partidos. Artículo de LWN recomendado: <a href="https://lwn.net/Articles/806466/">Developers split over split-lock detection</a>.</div><div style="text-align: left;"><br /></div><div style="text-align: left;"><ul style="text-align: left;"><li> Soporte de Autentificación de Punteros de ARM en el Kernel</li></ul><div style="margin-left: 40px; text-align: left;">Linux 5.0 añadió soporte para una extensión de ARM 8.3 llamada Autentificación de Punteros, que utiliza un código de autentificación de puntero para determinar si los punteros de un programa han sido modificados inesperadamente. Esto previene muchos fallos de seguridad, pero este soporte estaba limitado a espacio de usuario. En esta versión se añade soporte para el kernel arm64, que debería ayudar a proteger el kernel contra ciertos tipos de ataques. Artículo de LWN recomendado: <a href="https://lwn.net/Articles/718888/">ARM pointer authentication</a>.</div><div style="text-align: left;"><br /></div><div style="text-align: left;"><ul style="text-align: left;"><li> Soporte de protección de escritura en userfaultfd()</li></ul><div style="margin-left: 40px; text-align: left;">Esta versión añade soporte de protección de escritura a userfaultfd(), una llamada al sistema añadida en Linux 4.3 para permitir que un proceso gestione los fallos de página en espacio de usuario. Esto significa que los intentos de escribir en áreas del espacio de direcciones especificados con userfaultfd() podrán ser gestionados por el espacio de usuario. Esto es equivalente (pero más rápido) que usar mprotect(2) y un manejador de señal SIGSEGV. hugetblfs/shmem aun no están soportados. Para más detalles, vea la <a href="https://git.kernel.org/linus/57e5d4f278b9522646b49a3a97ebf5f2b8f9d4cf">documentación</a>. Artículo LWN recomendado: <a href="https://lwn.net/Articles/787308/">Write-protect for userfaultfd()</a>.</div><div style="text-align: left;"><br /></div><div style="text-align: left;"><ul style="text-align: left;"><li>bpf-lsm: Un Módulo de Seguridad Linux basado en BPF</li></ul><div style="margin-left: 40px; text-align: left;">La actual infraestructura del kernel destinada a proporcionar telemetría relacionada con la seguridad (audit, perf, etc) está separada de la aplicación de reglas de acceso (LSMs). Mejorar la información proporcionada por audit requiere cambios en el kernel, su lenguage de políticas y componentes de espacio de usuario. Es más, construir una nueva política MAC basada en la nueva telemetría requiere cambios a varios LSMs y a sus respectivos lenguajes de políticas. Esta versión añade un nuevo LSM que permite que los programas BPF se vinculen con los ganchos LSM existentes, con lo cual es posible tener una política de auditoría y MAC unificado y adaptable dinámicamente mediantes programas BPF. Artículo LWN recomendado: <a href="https://lwn.net/Articles/808048/">KRSI — the other BPF security module</a>.</div><div style="text-align: left;"><br /></div><div style="text-align: left;"><ul style="text-align: left;"><li>clone(): permitir crear procesos dentro de cgroups</li></ul><div style="margin-left: 40px; text-align: left;">Esta versió añade soporte en clone() para engendrar procesos en un cgroup diferente que el de su padre, lo cual significa que los llamantes pueden limitar los procesos e hilos desde el momento en que son engendrados. Un gestor de servicios puede engendrar directamente nuevos servicios en cgroups dedicados; la pequeña contabilidad que se pierde en el tiempo en que se tarda en mover el proceso al cgroup se elimina; las aplicaciones con hilos o incluso implementaciones de hilos pueden elegir crear un diseño de cgroups específico donde cada hilo es concebido directamente en un cgroup dedicado. Artículo LWN recomendado: <a href="https://lwn.net/Articles/807882/">Cloning into a control group</a>.</div><div style="text-align: left;"><br /></div><div style="text-align: left;"><ul style="text-align: left;"><li googl="true">Mejora de funcionamiento de perf con cgroups<br /></li></ul><div googl="true"><div style="margin-left: 40px; text-align: left;">Antes, perf sólo podía hacer perfilados de tareas en un cgroup específico y no había manera de saber a qué cgroup pertenecía la muestra actual. En esta versión, perf incorpora información en cada muestra, lo cual hace imposible perfilar más de un cgroup y usar una clave para ordenar por cgroup en perf report.</div><div style="margin-left: 40px; text-align: left;"><br /></div><div style="text-align: left;"></div>Y eso es todo. Como siempre, pueden encontrar la lista completa de cambios, en inglés, en <a href="https://kernelnewbies.org/Linux_5.7">esta página</a>.</div></div></div></div></div></div></div></div></div>Diegohttp://www.blogger.com/profile/18081775339476161685noreply@blogger.com3tag:blogger.com,1999:blog-7974522.post-55721044799893548942019-11-25T21:40:00.002+01:002019-11-25T21:40:54.870+01:00Las novedades de Linux 5.4Ya se ha <a href="https://lkml.org/lkml/2019/11/24/187">publicado Linux 5.4</a>. Las novedades de esta versión incluye el "kernel lockdown mode", con el que se pretende proteger los límites entre UID 0 y el kernel; virtio-fs, un driver virtio que permite a un huésped virtualizado montar sistemas de archivos del anfitrión; fs-verity, que permite detectar modificaciones no autorizadas en los archivos; dm-clone, que permite la clonación en vivo de targets de device-mapper; dos nuevas banderas en madvise() para mejor gestión de memoria de las aplicaciones en Android; soporte para nuevas GPUs Intel y AMD; soporte para el sistema de archivo exfat y eliminación del estatus experimental de erofs; soporte para haltpoll, un nuevo driver cpuidle que mejora el rendimiento en huéspedes virtualizados que quieren hacer polling en el loop idle; y blk-iocost, un controlador de cgroup E/S que intenta calcular mejor el coste de la E/S. Además, hay muchas otras mejoras y pequeños parches. La lista completa de cambios, en inglés, se encuentra <a href="https://kernelnewbies.org/Linux_5.4">aquí</a>.<br />
<br />
<br />
<b>· Kernel lockdown mode </b><br />
<br />
<br />
Esta versión incluye un modo opcional "kernel lockdown", que pretende fortalecer los límites entre UID 0 (root) y el kernel. Cuando se activa, se restringe la funcionalidad de varios aspectos del kernel. Las aplicaciones que dependen de acceso de bajo nivel o bien al hardware o al kernel podrían dejar de funcionar; por lo tanto debe evaluarse con antelación su activación. El propósito original de esta característica era honrar las protecciones anti-manipulación que se esperan de los entornos con arranque seguro UEFI, pero no está limitado a esa función.<br />
<br />
Se ha implementado Kernel Lockdown como un módulo de seguridad de Linux, que puede configurase en modo de integridad o lockdown. Si se configura con modo integridad, se desactivarán las características del kernel que permiten modificar el kernel. Si se configura con modo de confidencialidad, también se desactivarán las características que permiten a los programas extraer información del kernel (estas restricciones no sólo se aplicarán a los programas de usuarios normales, sino también, recordemos, al usuario root). La configuración puede hacerse a través de securityfs, con un parámetro de arranque o en tiempo de compilación.<br />
<br />
<b>· virtio-fs, un puente para compartir sistemas de archivos con huéspedes virtualizados</b><br />
<br />
Esta versión incluye virtio-fs, un driver virtio basado en FUSE que se utiliza para compartir sistemas de archivos entre huéspedes <-> anfitriones. Permite a un huésped montar un directorio que haya sido exportado desde el anfitrión. Aunque hay tecnologías similares que permiten este tipo de funcionalidad (NFS, virtio-9P), la proximidad entre VMs de virtio-fs permite aventajarles y proporcionar un rendimiento y unas semánticas de las APIs más similares a un sistema de archivos local que uno remoto.</-><br />
<br />
<-><b>· fs-verity, para la detección de modificaciones en archivos</b></-><br />
<->fs-verity es una capa que los sistemas de archivos pueden utilizar para soportar transparentemente la protección de integridad y autenticidad de archivos de sólo lectura. Es similar a dm-verity, pero funciona a nivel de archivos, en lugar de bloques. Es utilizado por Ext4 y F2FS.</-><br />
<-><br /></->
<->Los programas pueden utilizar una ioctl que provoca que el sistema de archivos construya un árbol Merkle para el archivo que persista en alguna ubicación asociada con el archivo. Opcionalmente, es posible firmar archivos con una clave cargada en el keyring. Tras esta operación, el archivo se convierte en un archivo de sólo lectura, y todas las lecturas del archivo serán verificadas contra el árbol Merkle del archivo, con lo que se podrán detectar cualquier modificación, intencionada o no. Los programas pueden también obtener con rapidez el hash raíz del archivo con otra ioctl, lo cual puede ser utilizado para una serie de funcionalidades de seguridad. Para más detalles lean la</-><-> <a class="https" href="https://www.kernel.org/doc/html/latest/filesystems/fsverity.html">documentación</a>.</-><br />
<br />
<-><b>· dm-clone</b></-><br />
<div class="line874">
<->dm-clone es un target de device-mapper que hace una copia de una fuente de sólo lectura en un dispositivo de destino: Presenta un dispositivo de bloques virtual que muestra inmediatamente todos los datos, y redirige las lecturas y escrituras cuando sea necesario. El uso principal de dm-clone es clonar un dispositivo de bloques remoto, de alta latencia, en un dispositivo rápido y local. El dispositivo montado es inmediatamente visible y la copia de datos ocurre en segundo plano, en paralelo con la E/S de usuario.</-></div>
<div class="line874">
<br /></div>
<div class="line874">
<-><b>· Soporte de nuevo hardware gráfico Intel/AMD</b></-></div>
<div class="line874">
<-></-></div>
<div class="line874">
<-></-></div>
<-><div class="line874">
Esta nueva versión añade soporte en el driver amdgpu para cuatro nuevos productos:: Navi 12/14, Arcturus y Renoir.<-></-><-> </-></div>
<div class="line874">
<br /></div>
<div class="line874">
<->También incluye las primeras partes del soporte del futuro Intel Tiger Lake.</-></div>
<div class="line874">
<-><br /></-></div>
<div class="line874">
<-><b>· Dos nuevas banderas en madvise(): MADV_COLD y MADV_PAGEOUT</b></-></div>
<div class="line874">
<-><b> </b>Para mejorar el uso de memoria en algunos sistemas (notablemente, Android), se han incorporado dos nuevas banderas a madvise(): MADV_COLD y MADV_PAGEOUT. Estas dos nuevas banderas complementan a MADV_DONTNEED y MADV_FREE añadiendo formas no destructivas de recuperar memoria libre.<b> </b></-></div>
<div class="line874">
<-><br /></-></div>
<div class="line874">
<->MADV_COLD advierte al kernel de que las páginas pueden ser reclamadas cuando haya presión de memoria pero los datos deberían preservarse para el futuro, esto puede reducir el desalojo de la memoria utilizada y por lo tanto mejorar el rendimiento. Como contraste con MADV_FREE, los contenidos de la región son preservados al margen de que después se escriba a las páginas.</-></div>
<div class="line874">
<-><br /></-></div>
MADV_PAGEOUT puede utilizarse por un proceso para marcar un rango de memoria como que no espera ser utilizado por un largo tiempo, de modo que el kernel reclame cualquier página de la LRU instantáneamente. El indicio puede ayudar al kernel a decidir qué páginas desalojar proactivamente. El acceso al rango tras una operación exitosa puede provocar fallos de página mayores, pero nunca perder los contenidos actualizados como ocurre con MADV_DONTNEED.</-><br />
<div class="line874">
<-><br /></-></div>
<div class="line874">
<-><b>· Erofs y exfat</b></-></div>
<div class="line874">
<->Esta saca a erofs fuera del espacio de staging. Incluído por primera vez <a href="https://kernelnewbies.org/Linux_4.19#New_experimental_EROFS_file_system">en Linux 4.19</a>, erofs es un sistema de archivos de sólo lectura, con un diseño moderno para escenarios en los que se necesitan medios de sólo lectura de alto rendimiento, como firmwares de teléfonos o livecds. <a href="https://lwn.net/Articles/796687/"></a> <br /><br />Esta versión también añade el sistema de archivos exfat al área staging.<br /> <br /><b>· Polling más eficiente en huéspedes virtualizados con haltpoll</b></-></div>
<div class="line874">
<->Esta versión incluye un driver cpuidle y un governor asociado llamados haltpoll. Estos dos mechanismos permiten a las CPUs virtuales continuar haciendo poll durante una determinada cantidad de tiempo antes de detenerse, lo cual proporciona una serie de ventajas considerables como evitar el coste de una VM-exit, que acaba traduciéndose en un mejor rendimiento. Para más detalles, lean la <a href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/Documentation/virtual/guest-halt-polling.txt?id=2cffe9f6b96fece065ee8522673c90e92ef2085d">documentación</a>.</-></div>
<div class="line874">
<-><br /></-></div>
<div class="line874">
<-><b>· blk-iocost, un controlador de E/S más preciso</b> </-></div>
<div class="line874">
<->Una de las dificultades de controlar los recursos de E/S es la dificultad de observar su coste. El ancho de banda y las operaciones por segundo pueden variar enormemente dependiendo del tipo de dispositivo y de los patrones de E/S utilizados. Esto es un reto para los controladores cgroup de E/S, que deben poder calcular el coste de la E/S para hacer su trabajo: a pesar de que <i> io.latency</i> proporciona la capacidad de priorizar y proteger unas E/S sobre otras de otros cgroups, en la práctica su protección es binaria - el cgroup con el objetivo con mejor latencia es protegido a pesar del resto.</-></div>
<div class="line874">
<br /></div>
<div class="line874">
<-></-></div>
<div class="line874">
Esta versoión incluye blk-iocost, un controlador con un modelo de coste de E/S que intenta ser más efectivo. Tiene un modelo donde cada E/S está clasificada como secuencial o aleatoria y se le da un coste base acorde. Cada E/S obtiene un coste bastante fiable, y distribuye la capacidad de E/S a cada cgroup de acuerdo con su peso jerárquico. Para más detalle, lean la documetación de <a class="https" href="https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html#io">io.cost.qos y io.cost.model</a><span class="anchor" id="line-68"></span><->.</-></div>
<div class="line874">
<br /></div>
<div class="line874">
<-><b>· Espacio de nombres en los símbolos del kernel </b> </-></div>
<div class="line874">
<->Para soportar los módulos, el kernel necesita exportar los símbolos de las funciones utilizadas por los módulos. Con más de 30k símbolos en el kernel actual, gestionar todos los símbolos no es siempre fácil. En esta versión, el kernel permite a los mantenedores de subsistemas particionar y categorizar sus símbolos exportados en nombres de espacios diferentes, lo cual facilita el control de los símbolos. Los autores de módulos deben importar los espacios de nombres que quieran utilizar.</-></div>
<div class="line874">
<br /></div>
<div class="line874">
<-></-></div>
<div>
Y eso es todo. Como siempre, pueden encontrar la lista completa de cambios, en inglés, en <a href="https://kernelnewbies.org/Linux_5.4">esta página</a>.</div>
<br />
<br />
<br />
<br />
<br />
<-></->Diegohttp://www.blogger.com/profile/18081775339476161685noreply@blogger.com12tag:blogger.com,1999:blog-7974522.post-44253288433080497882019-05-06T09:29:00.001+02:002019-05-06T09:29:05.318+02:00Las novedades de Linux 5.1<div googl="true">
Ya <a href="https://lkml.org/lkml/2019/5/5/278">se ha publicado</a> la versión 5.1 de Linux. Entre los cambios que trae consigo está versión se encuentra: <i>io_uring</i>, una nueva interfaz de alto rendimiento para E/S asíncrona; también se incluyen mejoras a fanotify que proporcionan una manera escalable de vigilar los cambios en sistemas de archivos grandes; se añade un método para permitir la entrega segura de señales en presencia de reutilización de PIDs; la memoria persistente puede utilizarse como RAM; los niveles de compresión Zstd en Btrfs son configurables; también se añade un nuevo gobernador cpuidle que toma mejores decisiones de gestión energética que el gobernador menu; todas las arquitecturas de 32 bits han añadido llamadas al sistema con time_t de 64 bits para afrontar el problema y2038; es posible arrancar desde un dispositivo de device-mapper sin usar initramfs; y el parcheo en vivo ha añadido soporte para parches acumulativos. Además, hay muchas otras mejoras y pequeños parches. La lista completa de cambios, en inglés, se encuentra <a href="https://kernelnewbies.org/Linux_5.1">aquí</a>.</div>
<div googl="true">
<br />
<br />
<b>1. E/S asíncrona de alto rendimiento con io_uring</b></div>
<br />
<div googl="true">
Linux soporta E/S asíncrona desde hace mucho tiempo. Sin embargo, la interfaz tiene un amplio número de problemas. No soporta, por ejemplo, E/S con búfers, sólo E/S sin buffers (O_DIRECT), que sólo utiliza un subconjunto de un subconjunto de aplicaciones. Incluso en esos casos, la E/S no era siempre asíncrona ni rápida. Todos los intentos de mejorar la interfaz existente han fracasado. </div>
<div googl="true">
<br /></div>
<div googl="true">
Esta versión incluye una nueva interfaz, io_uring, que trae a Linux E/S asíncrona rápida y escalable, tanto con búfers como sin ellos, y soporta también E/S asíncrona con polling. Para más detalles, lea <a href="http://kernel.dk/io_uring.pdf">este documento</a> (PDF) que explica las razones por las que se ha creado io_uring, su funcionamiento interno, y la interfaz de cara al usuario. Para detalles sobre el rendimiento, vea <a href="https://lore.kernel.org/linux-block/20190116175003.17880-1-axboe@kernel.dk/">este email</a>. <br />
<br />
Adicionalmente, se ha creado una <a href="http://git.kernel.dk/cgit/liburing/">librería, liburing</a>, para las aplicaciones que no necesitan o no quieran preocuparse de juguetear con los detalles de bajo nivel de la interfaz. Tiene ayudantes que permiten a las aplicaciones configurar una instancia io_uring y enviar/completar E/S in conocer los detalles más escabrosos de los anillos; continuará añadiendo ayudantes y más características con el tiempo.</div>
<div googl="true">
<br /></div>
<div googl="true">
<b>2. Mejoras en fanotify para una mejor monitorización del sistema de archivos</b></div>
<div googl="true">
<br />
A diferencia de otros sistemas operativos, Linux no proporciona un sistema eficiente para vigilar los cambios que ocurren en un sistema de archivos grande. La única manera de monitorizar eventos de modificación a un directorio es inotify, que escala mal con grandes árboles de directorios. La interfaz fanotify, introducida en <a href="https://kernelnewbies.org/Linux_2_6_36#Preliminary_merge_of_fanotify.2C_a_new_file_notification_interface">Linux 2.6.36</a>, tenía la pretensión de sustituir inotify y solucionar sus deficiencias, e inicialmente dió algunos pasos en esa dirección, pero la funcionalidad requerida para sustituir a inotify por completo.</div>
<div googl="true">
<br />
Esta versión (junto con los cambios añadidos en <a href="https://kernelnewbies.org/Linux_4.20#Core_.28various.29">Linux 4.20</a>) expanden inotify para proporcionar la funcionalidad "super block root watch", que es una manera escalable de observar los cambios en grandes sistemas de archivos. Para más detalles, lea <a href="https://github.com/amir73il/fsnotify-utils/wiki/Super-block-root-watch">el wiki del proyecto</a>.<br />
<br />
<b>3. Entrega segura de señales en presencia de reutilización de PID</b></div>
<div googl="true">
</div>
<div googl="true">
<br />
La llamada al sistema kill(2) opera con PIDs. Tras la salida y muerte de un proceso, su numero de PID puede ser reutilizado por otro proceso. Si un proceso envía una señal a un PID reutilizado, estará enviando la señal al PID equivocado. Este es un problema conocido con el diseño de Unix, y ha provocado <a href="https://lkml.org/lkml/2019/3/31/5">numerosos problemas de seguridad</a>. <br />
<br />
Tras considerar varias opciones, Linux ha añadido la llamada al sistema pidfd_send_signal(2), que utiliza descriptores de archivo de /proc/<pid> para referencias a struct pid. Incluso tras el reciclado de un número PID, el descriptor no cambiará y hará referencia al viejo PID y no al nuevo, lo cual permite enviar señales al PID que en verdad se desea.</pid></div>
<div googl="true">
<br /></div>
<div googl="true">
</div>
<div googl="true">
<b>4. Utilización de memoria persistente como RAM</b><br />
<br />
Linux soporta dispositivos de memoria persistente, pero normalmente son utilizados como dispositivos de almacenamiento. Algunas personas desean utilizar la memoria persistente como memoria volátil, están dispuestos a lidiar con las diferencias de rendimiento con la RAM, y quieren utilizar las APIs tradicionales de gestión de memoria en lugar de un asignador de memoria en espacio de usuario ubicado sobre el mmap() de un archivo DAX. Esta versión de Linux les permite hacer eso.</div>
<div googl="true">
</div>
<div googl="true">
<br />
<b>5. TEO, un gobernador alternativo a 'menu'</b></div>
<div googl="true">
<br /></div>
<div googl="true">
El <a href="https://www.kernel.org/doc/html/v5.0/admin-guide/pm/cpuidle.html">subsistema cpuidle</a> es la parte del kernel encargada de decidir qué estado de sueño profundo utilizar cuando la CPU no tiene nada que hacer (los estados de sueño más profundo ahorran más energía, pero cuesta más salir de ellos). Hay dos gobernadores cpuidle, "menu" y "ladder", cada uno con diferentes heurísticas. Sin embargo, se cree que el gobernador "menu" tiene una serie de deficiencias que han llevado a añadir una alternativa: TEO, Timer Events Oriented Governor, que parece ofrecer mejoras de rendimiento sin aumento del consumo de energía. Puede observarse el gobernador que está siendo utilizado en /sys/devices/system/cpu/cpuidle/current_governor_ro, y cambiar el gobernador por defecto en el arranque con el parámetro cpuidle.governor=teo.</div>
<div googl="true">
<br /></div>
<div googl="true">
<b>6. Más preparación para el año 2038</b><br />
<br />
Como parte del trabajo para prepararse para el problema del año 2038, esta versión incluye llamadas de sistema con time_t de 64 bits para todas las arquitecturas de 64 bits. Esto permite finalmente tener llamadas al sistema con 64-bit time_t en todas las arquitecturas.</div>
<div googl="true">
<br /></div>
<div googl="true">
<b>7. Compresión Zstd configurable para Btrfs</b> <br />
<br />
Btrfs tiene soporte de compresión Zstd desde <a href="https://kernelnewbies.org/Linux_4.14#zstd_compression_in_Btrfs_and_Squashfs">Linux 4.14</a>, pero no permitía configurar el nivel de compresión utilizado. Esta versión añade soporte para configurar el nivel de compresión en Btrfs, como se hace con zlib, utilizando la opción de montaje -o compress=zstd:nivel. Para ver los niveles disponibles y su impacto en el rendimiento y en el ratio de compresión, vea <a href="https://git.kernel.org/linus/3f93aef535c8ea03e40cd8acf0753b3e6ed33e96">este commit</a>.<br />
<br />
<b>8. Arranque desde un dispositivo de device mapper sin initramfs</b><br />
<br />
Para arrancar a un sistema de archivos ubicado en un dispositivo device mapper, se necesita un initramfs. Algunas personas, sin embargo, querrían o no pueden usar un initramfs. Esta versión permite utilizar targets DM en el proceso de arranque sin la necesidad de initramfs, con la ayuda de un complicado parámetro de arranque del kernel. Para más detalles vean <a href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/Documentation/device-mapper/dm-init.txt?id=6bbc923dfcf57d6b97388819a7393835664c7a8e">la documentación</a>.<br />
<br />
<b>9. parcheado en vivo: soporte para parches acumulativos</b><br />
<br />
Puede haber dependencias entre los parches en vivo. Si diferentes parches necesitan hacer diferentes cambios a la misma función, es necesario definir el orden en el que los parches serán instalados. Y implementaciones de funciones en los parches en vivo más nuevos deberán realizarse encima de los viejos, algo que pronto se convierte en una pesadilla para mantener, especialmente si alguien quiere eliminar uno de los parches que está en medio de la pila. Una solución elegante que se incluye en esta versión es algo llamado "reemplazo atómico". Permite la creación de "parches acumulativos" que incluyen todos los cambios de los parches viejos y los reemplazan por completo en una sóla transición. Como resultado, los autores de parches en vivo pueden mantener las fuentes para un sólo parche acumulativo. Para más detalles, vea la <a href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/livepatch/cumulative-patches.txt?id=c4e6874f2a2965e932f4a5cf2631bc6024e55021">documentación</a>. </div>
<div googl="true">
<br /></div>
<div googl="true">
Y eso es todo. Como siempre, pueden encontrar la lista completa de cambios, en inglés, en <a href="https://kernelnewbies.org/Linux_5.1">esta página</a>.</div>
Diegohttp://www.blogger.com/profile/18081775339476161685noreply@blogger.com12tag:blogger.com,1999:blog-7974522.post-10456028282922711702018-01-29T19:47:00.003+01:002018-01-29T19:47:37.704+01:00Las novedades de Linux 4.15Ya <a href="https://lkml.org/lkml/2018/1/28/173">se ha anunciado</a> la versión 4.15 de Linux. Además del código más actualizado para lidiar con Meltdown/Spectre, esta versión incluye soporte de modesetting y otras funciones avanzadas de display en el driver amdgpu; mejor gestión energética en sistemas con SATA Aggressive Link Power Management; un port para las CPUs RISC-V; soporte inicial para cifrado de memoria virtualizada en CPUs de AMD; soporte para la función de seguridad "User Mode Instruction Prevention" de Intel; soporte para el controlador de CPU en el sistema de control de recursos cgroupv2; una nueva bandera mmap(2) para permitir escritura directa a la memoria persistente que sea gestionada por sistemas de archivos; y muchos drivers nuevos y otras mejoras. La lista completa de cambios, en inglés, puede <a href="https://kernelnewbies.org/Linux_4.15">encontrarse aquí</a>. <br />
<br />
<br />
<br />
<b>· Meltdown/Spectre </b><b><br /></b>
Esta versión incorpora el último código para lidiar con Meltdown/Spectre. Para solucionar el problema Meltdown en CPUs Intel se incluye Page Table Isolation (puede ser desactivada con la opción del kernel <i>pti=off</i>). Para mitigar el problema Spectre v2, que afecta tanto a Intel como AMD, se requiere una versión de GCC que soporte la opción <i>-mindirect-branch=thunk-extern</i>, y puede desactivarse con la opción del kernel <i>spectre_v2=off</i> (si no tienes un compilador con esa funcionalidad, tendrás una mitigación mínima que sólo está en el código escrito en ensamblador, pero no en el código en C). La arquitectura PowerPC también está afectada por Meltdown en muchos modelos, y para prevenir ataques se incorpora la funcionalidad "<i>RFI flush of L1-D cache</i>". ARM también está afectada por Meltdown, pero las soluciones para ello se incluirán en la próxima versión. Tampoco se incluyen soluciones para Spectre v1. <br />
<br />
Se ha añadido un directorio <i>/sys/devices/system/cpu/vulnerabilities/</i> en el que se muestran las vulnerabilidades que afectan a la CPU y las mitigaciones que están siendo aplicadas.<br />
<br />
<br />
<b>· Modesetting y mucho mejor soporte de vídeo en el driver amdgpu</b> <br />
<br />
<br />
Esta versión incluye por fin el "display code" (132k LoC) que faltaban desde hace mucho tiempo en el driver amdgpu. Proporciona la funcionalidad "atomic modesetting" para hardware DCE8 (CIK), DCE10 (Tonga, Fiji), DCE11 (CZ, ST, Polaris), DCE12 (vega10), y DCN1 (RV); incluyendo HDMI y audio DP, DP MST, y muchas otras funciones avanzadas. Este soporte ha sido activado por defecto para Vega10 y Raven; el hardware anterior a vega10 aun no por dudas sobre la estabilidad, pero quien quiera probar puede activarlo manualmente con la opción del módulo <i>amdgpu.dc=1</i><br />
<br />
<br />
<b>· Mejor gestión energética en sistemas con SATA Link Power Management</b> <i><br /></i><br />
<br />Durante muchos, muchos años, Linux ha tenido problemas con los sistemas que tienen controladores SATA AHCI con ALPM (Aggressive Link Power Management), es decir, equipos con Haswell, Broadwell o Skylake. Debido a la escasa documentación disponible, Linux no ha soportado correctamente este ALPM, y sin un soporte correcto de esa función, el sistema no puede entrar en los modos de ahorro de energía profundo, lo que se traduce en un acortamiento notorio de la vida de la batería. A mejorar esta situación no ha ayudado que una gestión incorrecta de ALPM se tradujese con frecuencia en pérdida de datos.<br />
<br />En esta versión, se ha incluído un parche que intenta implementar ALPM imitando el comportamiento por defecto de Windows, lo cual proporciona mejoras en el consumo de energía sin poner en riesgo los datos. En un portátil de prueba T440, el ahorro en estado de reposo es de entre 0.9 y 1.2W.<br />
<br />
<br />
<b>· Nueva arquitectura: RISC-V</b><br />
<br />Esta versión incorpora las principales partes del port a CPUs RISC-V. <a href="https://en.wikipedia.org/wiki/RISC-V">RISC-V</a> es un con junto de instrucciones abierto que, a diferencia de las CPUs propietarias, puede usarse libremente para cualquier propósito, permitiendo a cualquier persona diseñar, manufacturar y vender chips y software RISC-V.<br />
<br />
Este port está a medias. Aunque compila y arranca, los drivers aun no están disponibles en esta versión.<br />
<br />
<br />
<b>· Soporte para cifrado de memoria virtualizada en chips AMD</b> <br />
<br />
<br />
Linux 4.14 ya añadió soporte para AMD Secure Memory Encryption, una característica que permite que la memoria en RAM esté cifrada, y se descifre y cifre de nuevo automáticamente cuando la CPU lea o escriba a la memoria RAM, protegiendo de ese modo sus contenidos de ataques físicos al sistema.<br />
<br />
Esta versión incorpora soporte inicial para Secure Encrypted Virtualization, que integra el cifrado de memoria en la arquitectura de virtualización AMD-V para así permitir máquinas virtuales cifradas; máquinas virtuales cuya memoria descifrada sólo puede ser accedida por la propia la máquina virtual, mientras que otras máquinas virtuales, o incluso el propio host, no pueden. Secure Encrypted Virtualization es especialmente útil en la nube, donde las máquinas virtuales no tienen por qué confiar en la empresa que la gestiona. Esta versión añade soporte para usar memoria cifrada en el huésped, los cambios necesarios para crear y gestionar huéspedes con memoria cifrada desde el anfitrión serán incluídos en las próximas versiones.<br />
<br />
<br />
<b>· Soporte para User-Mode Instruction Prevention</b><br />
<br />
Esta versión incorpora soporte para una característica de CPUs intel llamada "User Mode Instruction Prevention". Cuando está activada, esta característica desactiva para el espacio de usuario ciertas instrucciones como SGDT, SLDT, SIDT, SMSW y STR, lo cual dificulta la creación de ciertos exploits. Por requerimientos de emuladores como WineHQ y DOSEMI2, las instrucciones SGDT, SIDT y SMSW serán emuladas en el modo protegido y virtual-8086 and protected modes (no habrá emulación para los procesos en modo "long").<br />
<br />
<br />
<b>· Mejor restricción del uso de CPU con el controlador de CPU para cgroupv2</b><br />
<br />
La característica "control groups" con la jerarquía unificada, también llamado cgroup v2, fue <a href="http://kernelnewbies.org/Linux_2_6_24#head-5b7511c1e918963d347abc8ed4b75215877d3aa3">implementada in 2.6.24</a> y declarada como estable <a href="https://kernelnewbies.org/Linux_4.5#cgroup_unified_hierarchy_is_considered_stable">en 4.5</a>. Los controladores de recursos individuales tenían que ser portados a este nuevo diseño. La ausencia más llamativa era la del controlador de CPU, que proporciona a los cgroups la capacidad de limitar el uso de CPU para grupos de procesos. El problema es que para la inclusión del controlador de CPU se requería en primer lugar completar la funcionalidad de cgroupv2, específicamente el "thread mode", que fue incluido <a href="https://kernelnewbies.org/Linux_4.14#Control_Groups_thread_mode">en 4.14</a>, y que proporciona soporte para la gestión de recursos entre los <i>hilos</i> de un grupo. Tras todo ese trabajo llega a esta versión, por fin, el controlador de CPU para cgroupv2.<br />
<br />
<br />
<b>· Nueva bandera mmap(2) MAP_SYNC para permitir escritura directa a la memoria persistente que esté gestionada por sistemas de archivos.</b><br />
<br />
Esta versión introduce las banderas MAP_SYNC<i> </i>y MAP_SHARED_VALIDATE a mmap(2). Para más detalles, ver este artículo de LWN: <a href="https://lwn.net/Articles/731706/">Two more approaches to persistent-memory writes</a>.<br />
<br />
<br />
Y eso es todo. Como siempre, pueden encontrar la lista completa de cambios, y en inglés, en <a href="https://kernelnewbies.org/Linux_4.15">esta página</a>.
<br />
<div class="PageHeadline">
</div>
Diegohttp://www.blogger.com/profile/18081775339476161685noreply@blogger.com12tag:blogger.com,1999:blog-7974522.post-14399694626729369152017-05-02T11:33:00.000+02:002017-05-02T11:33:37.898+02:00 Las novedades de Linux 4.11Ya <a href="https://lkml.org/lkml/2016/12/11/102">se ha anunciado</a> la versión 4.11 de Linux. Esta versión añade soporte para cambiar el planificador de E/S en vivo en la capa de bloques multiqueue, soporte de journalling en la implementación RAID5 MD que permite cerrar el "write hole", una implementación de swap más escalable para el swap ubicado in SSDs, una nueva llamada al sistema que resuelve deficiencias de la actual interfaz stat(), una nueva herramienta perf ftrace que actúa como un frontend para la interfaz ftrace, soporte para dispositivos de almacenamiento que siguen la especificación <a class="external" href="https://en.wikipedia.org/wiki/Opal_Storage_Specification">OPAL</a>, soporte para el protocolo Shared Memory Communications-RDMA protocol definido en el <a class="external" href="https://tools.ietf.org/html/rfc7609">RFC7609</a> y búfers persistentes para la consola VGA. También se han incluido drivers nuevos y muchas otras mejoras y pequeños cambios. La lista completa de cambios, en inglés, puede <a href="https://kernelnewbies.org/Linux_4.11">encontrarse aquí</a>, como siempre.<b> </b><br />
<br />
<br />
<br />
<b>· Soporte para cambiar el planificador de E/S en vivo en la capa de bloques multiqueue</b><br />
<br />
Es bien sabido que la capa de bloques de Linux tiene diferentes planificadores de E/S (deadline, cfq, noop, etc), con diferentes características cada uno, y los usuarios pueden cambiar entre uno y otro en vivo. En Linux 3.13, <a href="https://kernelnewbies.org/Linux_3.13#head-3e5f0c2bcebc98efd197e3036dd814eadd62839c">la capa de bloques añadió un nuevo diseño multicola</a>, diseñada para el hardware moderno (SSD, NVMe). Sin embargo, este nuevo diseño multicola no incluía el soporte para planificadores de E/S. Esta versión resuelve ese problema con la inclusión de soporte de planificadores de E/S en el soporte multicola de la capa de bloques. También se ha incluído un port del planificador deadline (otros serán añadidos en el futuro).<b> </b><br />
<br />
<br />
<b>· Swapping escalable para SSDs</b><br />
<br />
Los dispositivos de almacenamiento como SSDs hacen que el uso de swap más atractivo, no sólo como una manera de lidiar con el exceso de uso de memoria, sino también como una técnica de mejora de rendimiento. Por ejemplo, los proveedores de servicios de nubes pueden hacer overcommit de memoria más agresivamente y meter más VMs en una plataforma con el swap ubicado en un dispositivo de almacenamiento rápido. Sin embargo, la implementación de swap fue diseñada para los discos duros tradicionales, para los que el rendimiento y la latencia del swap no era tan importante. Esta versión mejora la implementación de swap para hacerla más escalable, y por lo tanto más adecuada para ser utilizada con dispositivos de almacenamiento modernos.<b> </b><br />
<br />
<br />
<b>· Journaling en RAID5 para cerrar el write hole</b><br />
<br />
Basada en el trabajo que <a href="https://kernelnewbies.org/Linux_4.4#head-35757d5a814256056c5c4bb7c00e4fbc57ea69d3">empezó</a> en Linux 4.4, esta versión añade soporte de journaling para RAID4/5/6 en la capa MD (no confundir con el RAID de btrfs). Cuando se configura un dispositivo de journaling (típicamente NVRAM o SSD), el <a href="http://www.raid-recovery-guide.com/raid5-write-hole.aspx"> "write hole"</a> de RAID5 desaparece - un crash durante el modo degradado no puede causar corrupción.<b> </b><br />
<br />
<br />
<b>· statx(2), una alternativa moderna para stat(2)</b> <br />
<br />
Debido a varias carencias en la llamada al sistema stat(2) (tal y como no estar preparada para el problema y2038 o no funcionar bien con los sistemas de archivo de red), se ha estado trabajando durante años en una nueva llamada al sistema, y el resultado final ha sido statx(2), una nueva llamada que ha sido añadida en esta versión. Para más información: <a href="https://lwn.net/Articles/707602/">statx() v3</a>.<b> </b><br />
<br />
<br />
<b>· Nueva herramienta de perf, perf ftrace</b><br />
<br />
Perf ha añadido una nueva herramienta: perf ftrace. Esta herramienta pretende ser un simple front-end para la interfaz <a href="https://www.kernel.org/doc/Documentation/trace/ftrace.txt">ftrace</a>. En esta versión, perf ftrace sólamente soporta dos trazadores, <i>function_graph</i> y <i>function</i> (por defecto <i>function_graph</i>; pueden configurarse otros con la opción de configuración <i>ftrace.tracer</i>). En esta versión solamente se soporta el trazado de un sólo proceso, y la herramienta sólo lee el archivo <i>trace_pipe</i> y lo escribe a <i>stdout</i>. En el futuro se añadirán otras características.<b> </b><br />
<br />
<br />
<b>· Soporte para dispositivos de almacenamiento OPAL</b><br />
<br />
La <a href="https://en.wikipedia.org/wiki/Opal_Storage_Specification">Especificación de almacenamiento OPAL</a> es un conjunto de especificaciones para dispositivos de almacenamiento que mejora su seguridad. Por ejemplo, define una manera de cifrar los datos para que personas no autorizadas no puedan acceder a los datos. Es decir, es una especificación para discos auto-cifrados. Esta versión añade soporte de OPAL con controladores NVMe.<br />
<br />
<br />
<b>· Soporte para el protocolo SMC-R (RFC7609)</b><br />
<br />
Esta versión añade la implementación inicial del protocolo "Shared Memory Communications-RDMA" (SMC-R) tal y como está definido en el <a href="https://tools.ietf.org/html/rfc7609">RFC7609</a>. SMC-R es un protocolo de IBM que proporciona capacidades RDMA sobre RoCE de manera transparente para aplicaciones que usan sockets TCP. SMC-R no pretende reemplazar TCP, introduce una familia de protocolos PF_SMC. Las aplicaciones no requieren modificaciones más allá de especificar el uso de la nueva familia de sockets AF_SMC; las aplicaciones que no han sido modificadas incluso pueden ser utilizadas con ayuda de preloading de una librería.<br />
<br />
<br />
<b>· Búfers persistentes para las consolas VGA</b><br />
<br />
No se trata de una característica importante, especialmente para los usuarios de tmux/screen, pero probablemente fastidioso para otros: esta versión añade soporte opcional para que el historial de scrollback de las consolas no se borre cuando se cambia de una a otra.<br />
<br />
Y eso es todo. Como siempre, pueden encontrar la lista completa, y en inglés, en <a href="https://kernelnewbies.org/Linux_4.11">esta página</a>.
Diegohttp://www.blogger.com/profile/18081775339476161685noreply@blogger.com5tag:blogger.com,1999:blog-7974522.post-20261965633985929012017-03-10T20:42:00.001+01:002017-03-10T20:42:21.486+01:00Las novedades de Linux 4.9(Nota: esta es una entrada atrasada sobre la versión de kernel anterior a la actual)<br />
<br />
Ya <a href="https://lkml.org/lkml/2016/12/11/102">se ha anunciado</a> la versión 4.9 de Linux. Esta versión añade soporte para extents compartidos (soporte de <i>cp --reflink</i>) y soporte de copy-on-write para XFS; soporte para mapear la pila del kernel en memoria virtual; mejoras de BPF que ponen las capacidades de Linux a nivel de Dtrace; un nuevo algoritmo de congestión TCP llamado BBR; llamadas al sistema para usar la característica "protected keys" de Intel; soporte para el bus Greybus del Proyecto Ara; y un detector de latencias creadas por el firmware. También se han incluido drivers nuevos y muchas otras mejoras y pequeños cambios. La lista completa de cambios, en inglés, puede <a href="http://kernelnewbies.org/Linux_4.9">encontrarse aquí</a>, como siempre.<br />
<br />
<b>· Extents de datos compartidos + soporte de copy-on-write en XFS</b> <br />
<br />
Esta versión incorpora varias características a XFS, basadas en el "mapeado inverso" <a href="https://kernelnewbies.org/Linux_4.8#head-c0284ad982c4d5eb4b7731955237730aaeba3c44">introducido en la anterior versión</a>. Se añade el soporte para que dos extents de datos sean compartidos entre dos archivos. Es decir, se añade soporte para <i>cp --reflink=always</i>. Como consecuencia, también se añade soporte para deduplicacion de datos, y la posibilidad de descompartir datos mediante la interfaz FALLOC_FL_UNSHARE de fallocate(2).<br />
<br />
Esta versión también añade soporte de copy-on-write para datos: En lugar de sobreescribir los bloques existentes usados por un archivo, se copian los datos a un bloque nuevo y, una vez copiados los datos, se modifican los metadatos para que apunten a los nuevos bloques. <br />
<br />
Todas estas características suponen una gran cantidad de funcionalidad experimental que conllevan novedades en el formato de disco y en la infraestructura interna.<br />
<br />
<b>· Pilas mapeadas virtualmente</b><br />
<br />
Linux siempre ha mapeado la memoria utilizada por la pila del kernel directamente, algo que hace que en algunas situaciones con poca memoria pueda ser difícil crear nuevas pilas, y además no tiene protección de ningún tipo si el kernel excede el tamaño de la pila. Esta versión permite que la pila del kernel sea mapeada en memoria virtual, lo cual permite asignar memoria para nuevas pilas incluso en situaciones con poca memoria, y además añade una página de memoria virtual falsa a continuación de las de la pila, para que sea posible detectar si el kernel intenta sobrepasar los límites de la pila.<br />
<br />
<b>· Análisis BPF más eficiente</b><br />
Esta versión incluye la infraestructura necesaria para permitir que los programas BPF sean asociados a eventos perf de hardware y software, lo cual permite hacer análisis más complejos y eficientes que ponen las capacidades de análisis de Linux al nivel de DTrace, de acuerdo con Brendan Gregg (ver <a href="http://www.brendangregg.com/blog/2016-10-21/linux-efficient-profiler.html">su blog</a> para más información)<br />
<br />
<b>· Algoritmo BBR para el control de la congestión TCP</b><br />
Esta versión incorpora otro algoritmo de control de congestión TCP: BBR (Bottleneck Bandwidth and RTT). Generalmente, los algoritmos de control de congestión utilizan heurísticas basadas en la detección de pérdidas de paquetes. De acuerdo con los autores de BBR, este sistema ya no es válido para las redes modernas. En el Internet de hoy, los algoritmos basados en la detección de pérdidas de paquetes contribuyen a magnificar los problemas causados por el famoso "bufferbloat", provocando un rendimiento deficiente debido a que la existencia de grandes búfers en la red provocan sobrerreaciones y alteraciones bruscas del tráfico. El algoritmo BBR, en cambio, intenta establecer el ancho de banda máximo, sin prestar atención a las pérdidas de paquetes. El algoritmo BBR ha aumentado el rendimiento y reducido la latencia en las redes internas de Google, la página google.com y los servidores de Youtube.<br />
<br />
<b>· Llamadas de sistema para la característica "protection keys"</b><br />
<br />"Protection keys" es el nombre de <a href="https://kernelnewbies.org/Linux_4.6#head-6aea8343b906f7074bada5886c3328415dab2908">un sistema de protección de memoria por hardware que fue incluído en Linux 4.6</a>. Pero en esa versión, el uso de esta característica estaba limitado a que el kernel lo utilizara automáticamente, sin petición explícita de los programas, en APIs de alto nivel como <i>mmap(..., PROT_EXEC)</i> y <i>mprotect(ptr, sz, PROT_EXEC)</i>. <br />
<br />
En esta versión se incorporan llamadas al sistema que ofrecen una API completa que permite utilizar las "protection keys". Para más detalles, ver <a href="https://lwn.net/Articles/689395/">este artículo</a> o la <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/plain/Documentation/x86/protection-keys.txt">documentación</a>. <br />
<br />
<b>· Soporte del bus Greybus</b><br /> <br />
<br />Esta versión añade Greybus, un nuevo subsistema que da soporte al bus Greybus: un bus diseñado para el hardware modular, hot-pluggable, del difunto Proyecto Ara. A pesar de la muerte del proyecto, el código <a href="http://lkml.iu.edu/hypermail/linux/kernel/1610.0/01775.html">aun está siendo usado</a>. Para más detalles, ver este artículo: <a href="https://lwn.net/Articles/648400/">Greybus</a> <br />
<br />
<b>· Trazado de la latencia del hardware</b><br />
<br />El trazador de latencia del hardware es una herramienta diseñada para detectar grandes latencias provenientes de interrupciones causadas por el firmware (BIOS/EFI, SMI, etc), que el kernel desconoce por completo. El sistema funciona simplemente creando un proceso que ejecuta un bucle sin fin mientras mide el tiempo que transcurre, e intenta detectar lapsos de tiempo no esperados. Esta herramienta tiene como propósito comprobar si un sistema es adecuado para tareas de tiempo real<br />
<br /><br />
Y eso es todo. Como siempre, pueden encontrar la lista completa, y en inglés, en <a href="http://kernelnewbies.org/Linux_4.9">esta página</a>. Diegohttp://www.blogger.com/profile/18081775339476161685noreply@blogger.com2tag:blogger.com,1999:blog-7974522.post-53127133159859593152017-02-20T16:35:00.002+01:002017-02-20T16:35:58.187+01:00 Las novedades de Linux 4.10<br />
Ya <a href="https://lkml.org/lkml/2017/2/19/224">se ha anunciado</a> la versión 4.10 de Linux. Esta versión añade soporte para GPUs virtualizadas, una nueva herramienta 'perf 2c2' para el análisis de contención de cachelines en sistemas NUMA, un nuevo comando 'perf sched timehist' para obtener un historial detallado de la asignación de tareas, una mejora en la gestión de escritura a disco que debería proporcionar mejor interactividad bajo escritura intensa, un nuevo método de polling híbrido para dispositivos de bloque que utiliza menos CPU que el polling puro, soporte para dispositivos ARM como el Nexus 5 y 6 o Allwinner A64, una característica que permite asignar programas eBPF a cgroups, un caché experimental de RAID5 en el subsistema MD y soporte para la tecnología de Intel Cache Allocation Technology. También se han incluido drivers nuevos y muchas otras mejoras y pequeños cambios. La lista completa de cambios, en inglés, puede <a href="http://kernelnewbies.org/Linux_4.10">encontrarse aquí</a>, como siempre.<br />
<br />
<br />
<br />
<b>· Soporte para GPUs virtualizadas</b> <br />
<br />
Esta versión añade soporte para Intel GVT-g para KVM (KVMGT), una solución de virtualización de GPU, que está disponible a partir de la 4ª generación de procesadores Intel Core con Intel Graphics. Esta característica está basada en un nuevo framework de "Mediated devices" de VFIO. A diferencia de las soluciones de pass-through, los "dispositivos mediados" permiten que KVMGT ofrezca una GPU virtualizada que ofrece todas las características de una GPU real a todos y cada uno de los huéspedes virtualizados, al mismo tiempo que se mantiene un rendimiento casi similar al nativo. Para más detalles, ver estos papers: <br /><a href="https://www.usenix.org/conference/atc14/technical-sessions/presentation/tian">A Full GPU Virtualization Solution with Mediated Pass-Through</a> <br /><a href="http://www.linux-kvm.org/images/f/f3/01x08b-KVMGT-a.pdf">KVMGT: a Full GPU Virtualization Solution</a> <br /><a href="http://www.linux-kvm.org/images/5/59/02x03-Neo_Jia_and_Kirti_Wankhede-vGPU_on_KVM-A_VFIO_based_Framework.pdf">vGPU on KVM</a> (<a href="https://www.youtube.com/watch?v=Xs0TJU_sIPc">video</a>) <br /><a href="https://01.org/igvt-g/">Intel GVT main site</a><br />
<br />
<br />
<b>· Nueva herramienta 'perf c2c' para el análisis de contención de cachelines</b> <br />
<br />En los sistemas modernos con múltiples procesadores, los módulos de memoria están conectados físicamente a diferentes CPUs. En estos sistemas, llamados NUMA, los accesos de una CPU a la memoria del módulo que tiene conectado son más rápidos que los accesos a los módulos conectados a otros procesadores. Cuando un proceso tiene muchos hilos, cada hilo puede ejecutarse en diferentes CPUs al mismo tiempo; si esos hilos intentan acceder y modificar la misma memoria, pueden tener problemas de rendimiento debido a los costes en que se incurre para mantener los caches de las CPUs coordinados.<br />
<br />
<i>perf c2c</i> (de "cache to cache") es una nueva herramienta diseñada para analizar y encontrar esta clase de problemas de rendimiento en sistemas NUMA. Para más detalles, ver <a href="https://joemario.github.io/blog/2016/09/01/c2c-blog/">https://joemario.github.io/blog/2016/09/01/c2c-blog/</a> <br /><br />
<br />
<b>· Historial detallado de los eventos de la planificación de procesos con 'perf sched timehist'</b><br />
<br />'<i>perf sched timehist</i>' proporciona un análisis de los eventos de la planificación de procesos. Ejemplo: <span style="color: white;"><span style="background-color: black;">$ perf sched record -- sleep 1; perf sched timehist</span></span>.<br />
<br />
<pre> time cpu task name wait time sch delay run time
[tid/pid] (msec) (msec) (msec)
-------- ------ ---------------- --------- --------- --------
1.874569 [0011] gcc[31949] 0.014 0.000 1.148
1.874591 [0010] gcc[31951] 0.000 0.000 0.024
1.874603 [0010] migration/10[59] 3.350 0.004 0.011
1.874604 [0011] <idle> 1.148 0.000 0.035
1.874723 [0005] <idle> 0.016 0.000 1.383
1.874746 [0005] gcc[31949] 0.153 0.078 0.022</idle></idle></pre>
<br />
<br />
<b>· Mejora de la gestión de escritura a disco</b><br />
<br />
Desde el principio de los tiempos, el mecanismo encargado de escribir al disco los datos que los procesos han creado y que no han pedido escribir inmediatamente ("background writeback") ha tenido problemas. Cuando Linux escribe al disco todos esos datos en el transfondo, deberían tener poco impacto en los procesos que están ejecutándose. Pero desde hace muchísimo tiempo, no ocurre eso. Por ejemplo, si haces algo como <span style="background-color: black;"><span style="color: white;">$ dd if=/dev/zero of=foo bs=1M count=10k</span></span>, o intentas escribir archivos a un dispositivo USB, e intentas arrancar una aplicación pesada, el inicio prácticamente se eternizará hasta que el proceso de escritura termine. Estos problemas ocurren porque las escrituras intensas llenan las colas de la capa de bloques, y otras peticiones de E/S tienen que esperar mucho para ser atendidas (para más detalles, este <a href="https://lwn.net/Articles/682582/">artículo de LWN</a>).<br /><br />Esta versión añade un mecanismo que intenta frenar las escrituras intensas e impide que se monopolicen las colas de la capa de bloques, lo cual debería proporcionar una mayor sensación de interactividad en el escritorio. Esta opción debe ser configurada y, como cualquier cambio de estas características, puede no ser perfecto en esta primera versión.<br />
<br />
<br /><b>· Polling de bloques híbrido</b><br /><br />Linux 4.4 <a href="https://kernelnewbies.org/Linux_4.4#head-cd57c6abf8822152b3a175dd68c9610562b220d5">añadió</a> soporte para hacer polling en las peticiones a la capa de dispositivos de bloque. Se trata de un mecanismo a lo que NAPI hace en tarjetas de red, y puede mejorar el rendimiento para dispositivos de alto rendimiento (ej. NVM). Sin embargo, hacer polling constantemente puede consumir demasiada CPU, y en algunos casos incluso reducir el rendimiento. Esta versión de Linux incorpora un sistema híbrido: polling adaptativo. En lugar de hacer polling inmediatamente tras la petición de E/S, el kernel introduce un pequeño retraso. Por ejemplo, si el kernel espera que una petición de E/S vaya a ser atendida en 8 µsegundos, el kernel duerme durante 4 µsegundos, y luego empieza a hacer polling. Con este sistema híbrido, el kernel puede conseguir grandes reducciones de latencia como las del polling puro, pero sin tanto abuso de la CPU. Gracias a las mejoras en la obtención de estadísticas de la capa de bloques que han sido incluidas en esta versión, el kernel puede analizar el tiempo que tarda las peticiones de E/S en completarse y calcular automáticamente el tiempo que debería dormir<br />
<br />Este sistema híbrido está desactivado por defecto. Se ha añadido un nuevo archivo sysfs, <i>/sys/block/<dev>/queue/io_poll_delay</dev></i>, para configurarlo<br />
<br />
<b>· Mejor soporte de dispositivos ARM como el Nexus 5 y 6 o Allwinner A64</b><br />
<br />Como evidencia de los progresos que se están haciendo para acercar las diferencias entre los kernels Android y Linux, esta versión añade soporte para socs ARM como:<br />
- Huawei Nexus 6P (Angler) <br />
- LG Nexus 5x (Bullhead) <br /> - Nexbox A1 y A95X Android TV boxes <br /> - placa de desarrollo Pine64 basada en Allwinner A64 <br /> - placa Globalscale Marvell ESPRESSOBin basada en Armada 3700 <br /> - Renesas "R-Car Starter Kit Pro" (M3ULCB)<br />
<br />
<b>· Permitir asignar programas eBPF a cgroups</b> <br />
<br />Esta versión añade la capacidad de asociar programas eBPF a cgroups, con el propósito de que esos programas eBPF se apliquen automáticamente a todos los sockets de las tareas ubicadas en el cgroup. Se ha añadido un nuevo tipo de programa eBPF, <i>BPF_PROG_TYPE_CGROUP_SKB</i>. La llamada al sistema <a href="http://man7.org/linux/man-pages/man2/bpf.2.html">bpf(2)</a> ha sido extendida con dos nuevos comandos, <i>BPF_PROG_ATTACH</i> y <i>BPF_PROG_DETACH</i>, que permiten asociar y disociar programas a un cgroup. Esta característica es configurable (CONFIG_CGROUP_BPF). Artículo LWN recomendado: <a href="https://lwn.net/Articles/698073/">Network filtering for control groups</a> <br /><br />Esta versión también añade un nuevo tipo de programa eBPF, <i>BPF_PROG_TYPE_CGROUP_SOCK</i>. Al igual que los programas <i>BPF_PROG_TYPE_CGROUP_SKB</i>, pueden ser asignados a un cgroup, para permitir la modificación de un campo, <i>sk_bound_dev_if.</i><br />
<br /><b>· Cache de writeback RAID5 y soporte de "failfast"</b><br /><br />
Esta versión implementa un nuevo caché de writeback RAID5 en el subsistema MD (Multiple Devices). Su objetivo es agregar varias escrituras para poder hacer una escritura de "franja" completa, y de ese modo reducir el coste del proceso "read-modify-write" que daña el rendimiento de RAID5. Es beneficiosa para las cargas que hacen grandes escrituras secuenciales seguidas de fsync, por ejemplo. Esta característica está desactivada por defecto.<br />
<br />
Esta versión añade también soporte para "failfast". Los discos RAID que tengan muchos fallos de E/S serán marcados rápidamente como rotos, de modo que no se recurrirá a ellos en el futuro, lo cual puede mejorar la latencia de las peticiones de E/S.<br />
<br />
<b>· Soporte para Intel Cache Allocation Technology </b><br /><br />Esta es una característica de CPUs Intel que permite asignar políticas en los cachés L2/L3; ej. a una tarea de tiempo real se le podría asignar exclusivamente un espacio de caché. Para más detalles, ver este artículo de LWN: <a href="https://lwn.net/Articles/694800/">Controlling access to the memory cache</a>.<br />
<br />
<br />
Y eso es todo. Como siempre, pueden encontrar la lista completa, y en inglés, en <a href="http://kernelnewbies.org/Linux_4.10">esta página</a>.
Diegohttp://www.blogger.com/profile/18081775339476161685noreply@blogger.com5tag:blogger.com,1999:blog-7974522.post-39992413864040914792017-01-03T14:22:00.004+01:002017-01-03T14:22:55.259+01:00Las novedades de Linux 4.8<br />
<div dir="ltr" id="content" lang="en">
</div>
<div dir="ltr" id="content" lang="en">
</div>
<div dir="ltr" id="content" lang="en">
(Post muy retrasado)<br />
</div>
<div dir="ltr" id="content" lang="en">
La versión 4.8 de Linux <a href="https://lkml.org/lkml/2016/10/2/102">se anunció</a> el 2 de Octubre de 2016. Esta versión añade soporte para el uso de páginas gigantes en el caché de páginas; soporte de eXpress Data
Path, una opción para el tráfico de red programable y de alto rendimiento; soporte para mapeados inversos en XFS que son la fundación de varias mejoras que se añadirán en el futuro; verificación más estricta de las copias de memoria de espacio de usuario; soporte de etiquetado de seguridad en IPv6 (CALIPSO, RFC 5570); soporte para plugins de GCC; una nueva funcionalidad de virtio, vsocks, para facilitar la comunicación entre huéspedes y anfitriones; un nuevo algoritmo de congestión, TCP New Vegas; y la documentación ha sido convertida al formato
reStructuredText. También se han incluido drivers nuevos y muchas otras mejoras y pequeños cambios. La lista completa de cambios, en inglés, puede <a href="http://kernelnewbies.org/Linux_4.8">encontrarse aquí</a>, como siempre.<br />
<br />
<br />
<b>· Soporte para el uso de páginas gigantes transparentes en el caché de páginas</b></div>
<div dir="ltr" id="content" lang="en">
</div>
<div dir="ltr" id="content" lang="en">
Las páginas gigantes permiten la utilización de páginas mayores de 4Kb (en x86); cuando el sistema utiliza estas páginas automáticamente las llamamos "transparentes". Hasta ahora, Linux no soportaba el uso de páginas gigantes en el caché de páginas (páginas utilizadas para almacenar un caché de los sistemas de archivos). En esta versión se añade soporte para el uso de páginas gigantes transparentes en el caché de páginas cuando se utilicen sistemas de archivo tmpfs/shmem (el soporte para otros sistemas de archivo se añadirá en el futuro).</div>
<br />
Se puede controlar el uso de páginas gigantes en tmpfs utilizando la opción de montaje <i>huge=</i>, que puede recibir cuatro parámetros: <i>always</i> (se intentará utilizar páginas gigantes cada vez que se necesite una nueva página); <i>never</i> (no utilizar páginas gigantes - este es el valor por defecto); <i>within_size</i> (solo se utilizarán páginas gigantes si no sobrepasa el tamaño de archivo, también se respetan las pistas a <i>fadvise()/madvise()</i>); <i>advise</i> (sólo se utilizarán páginas gigantes si son solicitadas con <i>fadvise()/madvise()</i>).<br />
<br />
También hay un archivo en sysfs para controlar la asignación de páginas gigantes en montajes internos shmem: <i>/sys/kernel/mm/transparent_hugepage/shmem_enabled</i>. Este valor es utilizado para SysV SHM, memfds, shared anonymous mmaps (de /dev/zero de <i>MAP_ANONYMOUS</i>), objetos DRM de controladores GPU, ashmem. Además de las políticas señaladas arriba, <i>shmem_enabled</i> permite dos valores adicionales: <i>deny</i> (para ser usado en emergencias, para forzar la opción de páginas gigantes de todos los montajes); <i>force </i>(forzar el uso de páginas gigantes para todos - útil principalmente para pruebas)<br />
<br />
<br />
<b>· Soporte de eXpress Data Path </b><br />
<br />
XDP o eXpress Data Path proporciona una ruta para datos de red de alto rendimiento y programable. Proporciona procesamiento de paquetes con poca sobrecarga al nivel más bajo de la capa de software. La mayor parte de la gran mejora de velocidad viene del procesado de páginas-paquetes RX directamente fuera del anillo RX del driver, antes de que haya alguna asignación de estructuras de metadatos, como SKBs. Sus propiedades son: XDP está diseñado para alto rendimiento; XDP está diseñado para ser programable, se puede implementar nueva funcionalidad al vuelo sin requerir modificaciones en el kernel; XDP no intenta circunvalar el kernel, se integra en las rutas rápidas de la pila de red; XDP no reemplaza a la pila TCP/IP, la complementa y se coordina con ella; XDP no requiere hardware especializado. Para más información, ver <a href="https://www.iovisor.org/technology/xdp">https://www.iovisor.org/technology/xdp</a> y <a href="https://github.com/iovisor/bpf-docs/blob/master/Express_Data_Path.pdf">Express_Data_Path.pdf</a> <br />
<br />
<br />
<b>· Mapeado inverso en XFS</b> <br />
<br />
El mapeado inverso permite a XFS localizar al propietario de un bloque específico en el disco de manera precisa. Está implementado como una serie de btrees (uno por cada grupo de asignación) que llevan cuenta de los propietarios de los extents. Se trata, de hecho, de un "árbol de espacio utilizado" que se actualiza cuando el sistema de archivos asigna o libera extents y es por tanto coherente con los btrees de espacio libres.<br />
<br />
Esta infraestructura de mapeo inverso es el bloque fundacional de varias características que se añadirán a XFS en el futuro - reflink, copy-on-write, deduplicación, scrubbing online de metadatos y datos, reporte detallado de errores a los usuarios, y reconstrucción de sistemas de archivos dañados y corruptos significativamente mejorada. Hay muchas cosas nuevas que se incorporarán en las próximas versiones, y todo se basa en esta infraestructura. Por esa razón, se trata de una gran cantidad de código nuevo con nuevas características de formato de disco e infraestructura interna. Se trata de una característica experimental y no se recomienda su uso por el momento.<a href="https://git.kernel.org/torvalds/c/0cbbc422d56668528f6efd1234fe908010284082"></a><br />
<br />
<br />
<b>· Verificación más estricta de las copias de memoria desde el espacio de usuario</b><br />
<br />
Esta es una característica de seguridad portada de <a href="https://grsecurity.net/features.php#usercopy">Grsecurity</a>. Cuando el kernel copie memoria desde o hacia el kernel (mediante las funciones <i>copy_to_user()</i> y <i>copy_from_user()</i>), se harán comprobaciones extra para asegurarse de que los rangos de memoria afectados no son sospechosos. Esto imposibilita toda una serie de exploits de heap overflow y exposiciones de memoria del kernel. El impacto en el rendimiento es apenas notable.<br />
<br />
<br />
<b>· Soporte para plugins de GCC</b> <br />
<br />
Al igual que el anterior, esta característica ha sido portada de <a href="https://grsecurity.net/features.php#tabs-gcc">Grsecurity</a>. Permite el uso de <a href="https://gcc.gnu.org/wiki/plugins">plugins de GCC</a>, que son pequeños módulos de compilador cargables que permiten analizar, cambiar y añadir código durante la compilación y pueden utilizarse para la instrumentación en tiempo de ejecución y análisis estático de código. Grsecurity utilizar estos mecanismos para mejorar la seguridad. Esta versión incluye dos plugins: sancov, un plugin que se utiliza como ayuda para <a href="https://kernelnewbies.org/Linux_4.6#head-efb0246a2466d8855fad5394360a41f06028bab5">kcov</a>; y el plugin cyclomatic para el análisis de la complejidad ciclomática de una función<br />
<br />
<br />
<b>· virtio-vsocks para facilitar la comunicación entre huésped y anfitrión</b><br />
<br />
Esta version añade virtio-vsock, que proporciona sockets AF_VSOCK que permiten la comunicación entre aplicaciones del huésped y el anfitrión. A diferencia de virtio-serial, virtio-vsock soporta la API de sockets POSIX, de modo que las aplicaciones de red existentes necesitan pocas modificaciones. La API permite conexiones N:1, de modo que múltiples clientes pueden conectarse a un mismo servidor simultáneamente. El dispositivo tiene una dirección asignada automáticamente, de modo que no es necesaria configuración alguna dentro del huésped.<br />
<br />
<br />
<br />
<b>· Soporte de etiquetado de seguridad IPv6 (CALIPSO, RFC 5570)</b><br />
<br />
Esta versión implementa el <a href="https://tools.ietf.org/html/rfc5570">RFC 5570</a> - Common Architecture Label IPv6 Security Option (CALIPSO). Está diseñado para ser usado en entornos de red MLS confiables. CALIPSO es muy similar a su primo de IPv4 CIPSO, y esta característica está basada en gran medida en ese código.<br />
<br />
<br />
<br />
<b>· Nuevo algoritmo de control de congestión TCP New Vegas</b> <br />
<br />
Esta versión añade un nuevo algoritmo de control de congestión, TCP New Vegas, que es una actualización importante de TCP Vegas. Al igual que Vegas, New Vegas es un sistema para evitar la congestión basado en el retraso. Su mecanismo de filtrado es similar: utiliza las mejores mediciones en un periodo concreto para detectar y medir la congestión. Está desarrollado para coexistir con redes modernas donde los anchos de banda son de 10 Gbps o mayores, donde los RTTs son de décimas de microsegundos, etc.Puede encontrarse una descripción aquí: <a href="http://www.brakmo.org/networking/tcp-nv/">http://www.brakmo.org/networking/tcp-nv/</a><br />
<br />
<br />
<b>· Documentación convertida al formato reStructuredText </b> <br />
<br />
En un intento de modernizar la documentación del kernel, va a ser convertida al <a href="http://www.sphinx-doc.org/">sistema Sphinx</a>, que utiliza el formato <a href="http://docutils.sourceforge.net/rst.html">reStructuredText</a>.<br />
<br />
<br />
<br />
<br />
<br />
<br />
Estas son las novedades principales de este kernel. Como siempre, pueden encontrar la lista completa, y en inglés, en <a href="http://kernelnewbies.org/Linux_4.8">esta página</a>.
Diegohttp://www.blogger.com/profile/18081775339476161685noreply@blogger.com6tag:blogger.com,1999:blog-7974522.post-64991070880524881022016-07-25T15:50:00.000+02:002016-07-25T15:50:26.964+02:00Las novedades de Linux 4.7Ya se ha anunciado la versión 4.7 de Linux. Esta versión añade soporte para las recientemente puestas en venta GPUs Radeon RX 480 'Polaris', soporte para búsquedas de rutas de archivo paralelas en el mismo directorio, un nuevo gobernador de frecuencia experimental "schedutils" que debería ser más rápido y veloz que otros gobernadores, soporte para el mecanismo EFI "Capsule" que facilita las actualizaciones de firmware, soporte de controladores virtuales USB en la funcionalidad USB/IP para que los emuladores de teléfonos puedan funcionar como dispositivos USB reales, un módulo de seguridad llamado "LoadPin" que asegura que los módulos del kernel sólo se puedan cargar desde un sistema de archivos determinado, soporte para construir histogramas de eventos en la interfaz de trazado ftrace, soporte para asociar programas BPF a tracepoints del kernel, soporte para callchains en la utilidad perf trace, y soporte estable para la funcionalidad sync_file de Android. También se han incluido drivers nuevos y muchas otras mejoras y pequeños cambios. La lista completa de cambios, en inglés, puede <a href="http://kernelnewbies.org/Linux_4.7">encontrarse aquí</a>, como siempre.<br />
<br />
<br />
<br />
<b>· Soporte para GPUs Radeon RX 480 'Polaris'</b><br />
<br />
Como resultado de la nueva política de drivers libres de AMD, esta versión incluye soporte en el driver amdgpu para las recientísimamente puestas en venta GPUs Polaris, la nueva generación de <a href="http://www.amd.com/en-us/products/graphics/radeon-rx-series/radeon-rx-480">GPUs Radeon RX 480</a>. El soporte está al mismo nivel que el resto de dispositivos del driver.<br />
<br />
<br />
<br />
<b>· Búsquedas de ruta de archivo paralelas en el mismo directorio</b><br />
<br />
El caché de directorio (conocido como "dcache") es una de las partes más críticas del kernel, se trata de un caché de las rutas de los sistema de archivos, lo cual permite agilizar enormemente ciertas operaciones; por ejemplo, permite determinar si cierto archivo o directorio existe o no sin tener que leer datos del disco. Este cache usa un mutex para serializar las búsquedas de rutas en el mismo directorio.<br />
<br />
Esta versión permite hacer búsquedas de rutas en el mismo directorio; el mutex serializador ha sido sustituido por un semáforo de lectura-escritura. Esta mejora no se notará en la vastísima mayoría de casos, porque las búsquedas en el caché de directorios son muy rápidas y es muy raro que se convierta en un punto de contención. Pero para algunas cargas específicas que utilizan la búsqueda de rutas muy intensivamente, verán una mejora del rendimiento porque a partir de ahora podrán hacerse en paralelo. La mayor parte de los sistemas de archivos han sido convertidos para utilizar esta característica.<br />
<br />
<br />
<b>· Nuevo gobernador de frecuencia experimental 'schedutils'</b><br />
<br />
Esta versión incorpora un nuevo gobernador para el subsistema de escalado de frecuencias (cpufreq). Hay dos grandes diferencias entre este nuevo gobernador y los existentes. Primero, schedutils utiliza información proporcionada directamente por el planificador de procesos. Segundo, puede invocar los drivers cpufreq y cambiar la frecuencia más rápidamente.<br />
<br />
Lo que esto significa es que el tiempo que tarda el gobernador en hacer cambios de frecuencia y la calidad de las decisiones tomadas mejora respecto a anteriores gobernadores. Nótese que este nuevo gobernador es muy simple, y está considerado como una base sobre la que fundar futuros cambios que mejoren la integración entre el planificador de procesos y la gestión de energía. Sin embargo, funciona y los resultados preliminares son prometedores. Este gobernador comparte algunos valores tuneables con los otros gobernadores.<br />
<br />
<br />
<b>· S</b><b>oporte para construir histogramas de eventos en la interfaz de trazado ftrace</b><br />
<br />
Los "Hist triggers" son una funcionalidad que se incorpora a ftrace, la infraestructura de trazado de Linux disponible <a href="https://kernelnewbies.org/Linux_2_6_27#head-27c23aa79ee6da975ef95b4fff381ace1667a264">desde 2.6.27</a> que está embebida en el kernel y disponible en <i>/sys/kernel/debug/tracing.</i> Esta versión añade el comando "hist" a ftrace, que permite construir "histogramas" de eventos, agregando el número de eventos en una tabla hash. Como ejemplo, vamos a suponer que un usuario quiere conseguir una lista de bytes leídos por cada proceso en el sistema. Se puede hacer con el comando "hist" de la siguiente manera:<br />
<br />
<blockquote class="tr_bq">
<span style="background-color: black;"><span style="color: white;"># echo 'hist:key=common_pid.execname:val=count:sort=count.descending' > /sys/kernel/debug/tracing/events/syscalls/sys_enter_read/trigger </span></span></blockquote>
<br />
Lo que hace este extraño comando es escribir un comando al archivo <i>trigger</i> del evento <i>sys_enter_read</i> (el evento que corresponde a entrar en la llamada al sistema read(), es decir, intentar leer un archivo). Cuando se produzca el evento, se ejecutará un comando hist (<i>hist:</i>) que significa lo siguiente: cada vez que se dispare el evento, leer el PID (<i>common_pid</i> - puedes ver todos los campos posibles del evento en el archivo <i>/sys/kernel/debug/tracing/events/syscalls/sys_enter_read/format</i>) y convertirlo a nombre de proceso (sufijo <i>.execname</i>); esto será usado como clave (<i>key=</i>) en el histograma. El parámetro v<i>al=count</i> hace que se lea también el campo<i> count</i>, que en el evento <i>sys_enter_read</i> se refiere al número de bytes leídos. Finalmente, tras el separador <i>:</i>, el parámetro <i>sort=count.descending</i> hace que el comando ordene el resultado por el campo <i>count</i> en orden descendiente. La salida resultante es esta:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://i.imgur.com/WrHOZpW.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;" title=""><img border="0" src="http://i.imgur.com/WrHOZpW.png" height="416" title="" width="640" /></a></div>
<br />
Esta salida muestra qué procesos han leído archivos, cuantos bytes (<i>count</i>), y con cuanta frecuencia (hitcount, que no fue especificado en el comando pero se incluye por defecto).<br />
<br />
Como se puede observar, esta pequeña herramienta permite hacer análisis muy útiles del sistema, y si bien ftrace no puede competir (ni lo pretende) con herramientas de trazado más potentes como LTTng, perf o SystemTap, puede ser una herramienta muy conveniente. Para más información, puedes ver la <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/trace/events.txt?id=db1388b4ffa9e31e9ff0abacc3bdb121bec8c688#n516">documentación sobre hist triggers</a>, or leer este post recomendado de Brendan Egg: <a href="http://www.brendangregg.com/blog/2016-06-08/linux-hist-triggers.html">Hist Triggers in Linux 4.7</a>. Para más documentation sobre ftrace, ver <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/plain/Documentation/trace/ftrace.txt">Documentation/trace/ftrace.txt</a><br />
<br />
<br />
<b>· Soporte para callchains en la utilidad perf trace</b><br />
<br />
En esta versión, <i>perf trace</i> añade la habilidad de mostrar callchains cada vez que el proceso a trazar encuentra una llamada al sistema. Puedes probarlo con comandos como <span style="font-family: "courier new" , "courier" , monospace;"><span style="background-color: black;"><span style="color: white;"># perf trace --call dwarf ping 127.0.0.1</span></span></span>. Puedes mostrar callchains para los eventos deseados: <span style="font-family: "courier new" , "courier" , monospace;"><span style="background-color: black;"><span style="color: white;"># perf trace --event sched:sched_switch/call-graph=fp/ -a sleep 1</span></span></span>. El trazado de fallos de página (options -F/--pf) también lo soportan, por ejemplo, para trazar las llamadas a write() y los fallos de página con callchains mientras se inicia firefox, puede hacerse con<span style="background-color: black;"><span style="color: white;"><span style="font-family: "courier new" , "courier" , monospace;"> # perf trace -e write --pf maj --max-stack 5 firefox</span></span></span>. Una análisis de perf trace con callchains de todos los procesos de un sistema completo <a href="https://fedorapeople.org/%7Eacme/perf/perf-trace--call-graph-dwarf--all-cpus.txt">puede encontrarse aquí</a>.<br />
<br />
<br />
<b>· Permitir que los programas BPF usen tracepoints</b><br />
<br />
Los <a href="https://www.kernel.org/doc/Documentation/trace/tracepoints.txt">tracepoints</a> son una suerte de printf()s dinámicos que los desarrolladores introducen en su código para que <a href="https://www.kernel.org/doc/Documentation/trace/tracepoint-analysis.txt">puedan ser utilizados más tarde</a> para analizar el comportamiento del sistema. Los Tracepoints pueden ser utilizados por muchas utilidades: LTTng, perf, SystemTap, ftrace...pero no podían ser utilizados por programas BPF<br />
<br />
Esta versión añade un nuevo tipo de programa BPF (BPF_PROG_TYPE_TRACEPOINT) que puede usarse para construir programas BPF que puedan recoger datos de los tracepoints y procesarlos dentro del programa BPF. Esta alternativa puede ser más rápida que acceder a los tracepoints mediante kprobes, puede hacer las interfaces de los programas de trazado más estable, y permite la construcción de herramientas de trazado más complejas.<br />
<br />
<br />
<b>· Soporte para el mecanismo 'Capsule' de EFI</b><br />
<br />
Esta versión añade soporte para el mecanismo 'Capsule' de EFI, que permite pasar a EFI archivos de datos. EFI los valida y toma decisiones de acuerdo con sus contenidos. El uso más común para este mecanismo es incluir actualizaciones de firmware en una Capsule para que EFI haga la actualización en el próximo reinicio. Los usuarios pueden subir datos a Capsule escribiendo el firmware en el dispositivo /dev/efi_capsule_loader device.<br />
<br />
<br />
<b>· Soporte para controladores de USB virtuales en USB/IP</b> <br />
<br />
<a href="http://kernelnewbies.org/Linux_3.17#head-ad2bdd52ff1be7c7fc7cb3045a4cfd6032514933">USB/IP</a> permite compartir dispositivos USB sobre la red. Los dispositivos a compartir necesitan, sin emabrgo, ser reales. Esta versión soporte la capacidad de crear dispositivos USB virtuales sin necesidad de tener un dispositivo USB físico, tal sólo utilizando el subsistema de <a href="https://www.kernel.org/doc/htmldocs/gadget/index.html">USB gadgets</a>. <br />
<br />
Esta característica tiene varios usos; el más obvio (el que ha motivado su desarrollo) es la mejora de la emulación de teléfonos en los entornos de desarrollo. Los teléfonos emulados pueden ahora conectarse a la máquina del desarrollador, o a una virtual, mediante USB/IP, y así utilizarlos como si fuera un teléfono físico. También es útil, por razones obvias, para pruebas y experimentos.<br />
<br />
<br />
<b>· El mecanismo de fencing de Android, sync_file, se considera estable</b><br />
<br />
En esta versión, el código sync_file que estaba en el directorio de pruebas <i>staging</i>/, ha sido movido al kernel principal. Sync_file es una API desarrollada para Android para cubrir las deficiencias del mecanismo de <i>fencing</i> de Linux; para los interesados se pueden encontrar más detalles en la documentación oficial, <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/sync_file.txt?id=c784c82a3fd64b322015b92016fc980be705c176">Documentation/sync_file.txt.</a><br />
<br />
<br />
<b>· LoadPin, un módulo de seguridad para restringir el origen de los módulos del kernel</b> <br />
<br />
LoadPin es un módulo de seguridad que se asegura de que todos los archivos cargados por el kernel (módulos del kernel, firmware, imágenes kexec, políticas de seguridad, etc) tengan origen en un mismo sistema de archivos. Las expectativas son que ese sistema de archivos sea de sólo lectura, como por ejemplo un DVD o dm-verity (esta característica viene de ChromeOS, donde el sistema principal está verificado criptográficamente con dm-verity). Los sistemas con este tipo de sistemas de archivos podrán con este sistema forzar las restricciones citadas sin tener que recurrir a firmar criptográficamente los módulos (algo que Linux <a href="http://kernelnewbies.org/Linux_3.7#head-a04c2b7827323d26a659b3b7cdf759747bb400d2">también soporta</a>), lo cual es obviamente beneficioso para la seguridad<br />
<br />
<br />
Estas son las novedades principales de este kernel. Como siempre, pueden encontrar la lista completa, y en inglés, en <a href="http://kernelnewbies.org/Linux_4.7">esta página</a>.
Diegohttp://www.blogger.com/profile/18081775339476161685noreply@blogger.com1tag:blogger.com,1999:blog-7974522.post-82475330820498542682016-06-14T16:16:00.002+02:002016-06-14T16:16:47.914+02:00Apple ya tiene su ZFS: APFSZFS fue una revolución en el mundo de los sistemas operativos de propósito general, hasta el punto que se puede afirmar tajantemente que el sistema operativo que no tenga un sistema de archivos inspirado en él, está obsoleto. En Apple no son tontos y <a href="http://www.osnews.com/story/14473/Apple_Interested_in_Solaris_ZFS/">en seguida se interesaron al menos en facilitar el uso de ZFS</a>, pero acabaron abandonando la idea por problemas de licencia. Aun así, surgieron rumores de que Apple estaba desarrollando un sustituto de HFS+, sin que llegaran nunca a nada.<br />
<br />
Hoy, en su conferencia para desarrolladores, <a href="https://developer.apple.com/library/prerelease/content/documentation/FileManagement/Conceptual/APFS_Guide/Introduction/Introduction.html#//apple_ref/doc/uid/TP40016999">Apple ha anunciado su nuevo sistema de archivos APFS</a>. No se han dado muchos detalles, pero no se diferencia en nada de lo que se podría esperar de un clon de ZFS. Habrá que esperar hasta el año que viene para que den más detalles y publiquen el código fuente: APFS está tan verde, que ni tan siquiera garantizan la estabilidad del formato de disco.<br />
<br />
Sorprende que Apple, con sus inacabables recursos monetarios, se haya tomado tanto tiempo en crear un clon de ZFS: todos sus sistemas usan aun HFS+ (prueba de que, como se ha sugerido en el pasado en este blog, una implementación rápida y estable de un sistema de archivos es mucho más importante en la práctica que las campanitas y luces de colores de un formato de disco nuevo). Un servidor esperaba a APFS años mucho antes; <a href="http://diegocg.blogspot.com.es/2012/01/windows-y-su-nuevo-sistema-de-archivos.html"> hace cuatro años</a> predecía,
erróneamente, que veríamos un ZFS de Apple antes de ver ReFS -el ZFS de Microsoft, recuerden- en los
Windows de escritorio.<br />
<br />
Pero sobre todo, lo que esperaba de Apple es que se atreviese a ir más allá de los sistemas de archivo jerárquicos. Tras haber contratado al desarrollador del sistema de archivos de BeOS, uno se esperaba que se atreverían a copiar su implementación de atributos extendidos, pero no parece haber ninguna innovación en ese frente. No pierdo la esperanza de que lo tengan reservado para el futuro.Diegohttp://www.blogger.com/profile/18081775339476161685noreply@blogger.com1tag:blogger.com,1999:blog-7974522.post-89723080739358329682016-06-02T19:55:00.000+02:002016-06-02T19:55:09.266+02:00Las novedades de Linux 4.3(Tras un larguísimo retraso, esta es la lista de cambios de Linux 4.3)<br />
<br />
Ya se <a href="https://lkml.org/lkml/2015/11/1/202">ha anunciado</a> la versión 4.6 de Linux. Esta versión elimina el sistema de archivos Ext3 (a partir de ahora los sistemas de archivo Ext3 se tendrán que montar con Ext4, que siempre los ha soportado). También añade la llamada al sistema userfaultfd() para gestionar fallos de páginas desde espacio de usuario; la llamada al sistema membarrier() para enviar barreras de memoria a un conjunto de hilos; un controlador de PIDs para limitar el número de PIDs que puede haber en un cgroup; "ambient" capabilities para hacer el sistema de capabilities menos difícil de usar; un sistema para conseguir mejores estadísticas sobre la memoria que está siendo utilizada por un proceso; soporte para Identifier Locator Addressing de IPv6, que permite implementar túneles o virtualización de redes sin encapsulación; soporte para Virtual Routing and Forwarding Lite, túneles de red ligeros, y muchas otras mejoras y nuevos controladores. La lista completa de cambios, en inglés, puede <a href="http://kernelnewbies.org/Linux_4.3">encontrarse aquí</a>, como siempre. <br />
<br />
<br />
<b>· Eliminación del sistema de archivos Ext3</b><br />
Se ha eliminado el sistema de archivos Ext3. La motivación es que los sistemas de archivo Ext3 siempre han estado soportados por Ext4, que de hecho Ext4 se creó pensando en sustituir Ext3, y que las principales distribuciones llevan ya mucho tiempo utilizando Ext4 para montar sistemas de archivos Ext3. Ahora que Ext4 es bastante estable, los mantenedores creen adecuado librarse de él.<br />
<br />
<b>· userfaultfd(), una llamada al sistema para gestionar fallos de página en espacio de usuario</b><br />
<br />
Un fallo de página es algo que ocurre cuando un proceso que tiene alguna cosa mapeada en su espacio de direcciones, por ejemplo, un archivo, pero ese archivo no está en la memoria RAM: al tratar de acceder al archivo, se produce un fallo de pagina. El kernel es quien, normalmente, se ocupa de gestionar ese fallo de página: carga la porción del archivo en memoria.<br />
<br />
<br />
En esta versión, Linux añade soporte para gestionar fallos de página en espacio de usuario a través de una nueva llamada al sistema: userfaultfd(). La ventaja de esta llamada al sistema comparada con las operaciones de gestión de memoria habituales como mremap()/mprotect() es que es mucho más ligera.<br />
<br />
El principal usuario de esta llamada al sistema es QEMU, que puede usar esta llamada al sistema para implementar migración en vivo post-copia: se migran las VMs de un host a otro sin migrar su memoria, lo cual hace que la migración sea mucho más rápida, y una vez migrada la VM, QEMU utiliza userfaultfd() para ir transfiriendo la memoria al nuevo host a medida que ocurren fallos de página.<br />
<br />
<b>· membarrier(), una llamada al sistema para enviar barreras de memoria a un conjunto de hilos </b> <br />
<br />Esta versión añade una nueva llamada al sistema, <a href="http://man7.org/linux/man-pages/man2/membarrier.2.html">membarrier(2)</a>, que ayuda a distribuir los costes de las <a href="https://es.wikipedia.org/wiki/Barrera_%28inform%C3%A1tica%29">barreras de memoria</a> en espacio de usuario utilizadas para ordenar los accesos a memoria en sistemas multicore, y lo logra transformando parejas de barreras de memoria en parejas consistentes en membarrier(2) y una barrera de compilador. Para las primitivas de sincronización que distinguen entre el lado de lectura y el de escritura (por ejemplo, RCU, read-write locks), el lado de la lectura puede acelerarse significativamente con esta llamada al sistema, ya que se mueve la sobrecarga de la barrera de memoria al lado de la escritura. La idea fundamental es hacer que las CPUs ejecuten las barreras solamente cuando se requiere sincronización por parte del hilo que modifica datos, a diferencia de ejecutar las barreras antes y después toda vez que se acceden los datos desde un hilo de lectura.<br />
<br />
<b>· Nuevo controlador de PIDs para limitar el número de PIDs en los cgroups.</b> <br />
<br />Esta versión añade un controlador de PIDs que permite limitar el número de procesos que pueden crearse dentro de un cgroup. Los PIDs son un recurso fundamentalmente global, porque es bastante fácil acabar con todos los PIDs posibles antes de alcanzar otros límites de recursos. Como resultado, es posible paralizar el sistema. El controlador de PIDs está diseñado para prevenir estos abusos.<br />
<br />
<br />
Esencialmente, se trata de una implementación del límite RLIMIT_NPROC, sólo que se aplica a un cgroup en lugar de a un árbol de procesos. Sin embargo, hay que notar que las operaciones de añadir PIDs a un cgroup manualmente no están afectadas por el límite, sólo están limitados los procesos creados a través de fork().<br />
<br />
Para usar este controlador de PIDs, hay que configurar el número máximo de tareas en pid.max. El número de procesos disponibles en el cgroup es proporcionado por pids.current. Para que el cgroup no tenga límite de procesos, se puede configurar pid.max a "max".<br />
<br /><b>· Ambient capabilities</b><br />
<br />En Linux, hay un número de <a href="http://man7.org/linux/man-pages/man7/capabilities.7.html">capabilities</a> ("capacidades") definidas por el kernel. Para ejecutar varias operaciones privilegiadas, los procesos pueden ejercer las capacidades que tengan asignadas. Cada proceso tiene cuatro máscaras de capacidades: "effective", "permitted", "inheritable", y "bounding set". Cuando el kernel comprueba la validez de las capacidades comprueba la máscara "effective", el resto de máscaras sirven para modificar las capacidades que pueden estar en "effective"<br />
<br />
Debido a los defectos de diseño de las capacidades de Linux (artículo de LWN recomendado al respecto: <a href="https://lwn.net/Articles/632520/">Inheriting capabilities</a>), la herencia de capacidades no es muy útil. Para resolver los problemas, esta versión añade una quinta máscara llamada máscara "ambient". Esta máscara hace lo que la mayor parte de la gente esperaría que hiciera la máscara "inheritable". No se puede cambiar ningún bit de capacidades en "ambient" si no está previamente en "inheritable" y "permitted". Eliminar un bit de "permitted" o "inheritable" elimina ese bit de "ambient". Esto asegura que los programas que quieran intentar desprenderse de capacidades pueden hacerlo, sin complicaciones. Como la herencia de capacidades en Linux actualmente es tan chapucera, configurar prctl(PR_SET_KEEPCAPS,...), usar setresuid() para cambiarse a una uid no-root, y después llamar a execve(), tiene como efecto que se desactivan las capabilities. Por lo tanto, setresuid() de root a no-root limpia la máscara "ambient" al menos que no esté activada SECBIT_NO_SETUID_FIXUP. <br />
<br />
Si eres no-root pero tienes una capacidad, puedes añadirla a "ambient". Si lo haces, tus hijos también tendrán esa capacidad en "ambient", "permitted" y "effective". Por ejemplo, puedes configurar CAP_NET_BIND_SERVICE en "ambient", y tus hijos podrán, automáticamente, hacer bind() a puertos con números bajos. Los usuarios sin privilegios pueden crear espacios de nombres de usuario, mapearse ellos mismos a una uid no-cero, y crear árboles de procesos privilegiados y no privilegiados (relativos a su espacio de nombres).<br />
<a href="https://lwn.net/Articles/632520/"></a> <br />
<br />
<b>· page tracking, una manera más precisa de medir la memoria utilizada por las aplicaciones</b><br />
Saber qué páginas de memoria están siendo accedidas por una carga determinada y cuáles es útil para saber el tamaño de trabajo de la carga, lo cual es útil para configurar la aplicación, decidir en qué nodo debe ejecutarse, o configurar límites de memoria. Actualmente, la única manera de estimar la cantidad de memoria que no está siendo usada es /proc/PID/clear_refs y /proc/PID/smaps: el usuario puede eliminar el bit de acceso de todas las páginas de un determinado proceso escribiendo "1" al archivo clear_refs, esperar un tiempo, y contar la memoria que está siendo utilizada en la sección "Referenced" del archivo smaps. Sin embargo, este método tiene dos inconvenientes serios: 1) no puede contar las memoria de archivo que no está mapeada (ej, los archivos no mapeados, accedidos mediante read()/write()) 2) limpiar el bit de acceso de las páginas distorsiona la gestión de memoria.<br />
<br />
Para resolver esos problemas, esta versión introduce una nueva manera de analizar el uso de memoria. Para estimar la cantidad de páginas que no están siendo usadas por una aplicación, se deben seguir los siguientes procesos:<br />
· Marcar todas las páginas de la tarea en cuestión, configurando los bits correspondientes en /mm/page_idle/bitmap (este archivo implementa un bitmap donde cada bit representa una página de memoria). Las páginas a ser marcadas pueden encontrase en /proc/PID/pagemap, si se trata de un proceso, o /proc/kpagecgroup (un nuevo archivo) si se trata de una carga ubicada en un cgroup.<br />
· Esperar a que la carga en cuestión haga su trabajo<br />
· Leer /sys/kernel/mm/page_idle/bitmap y contar el número de bits que han cambiado<br />
<br />
<b>· Soporte para IPv6 Identifier Locator Addressing </b><br />
<br />
Esta versión añade soporte para Identifier Locator Addressing, un mecanismo diseñado para permitir la implementación de túneles o virtualización de redes sin encapsulación. El concepto básico de ILA es que una dirección IPv6 es dividida en dos partes de 64 bits: localizador e identificador. El identificador es la identidad de la entidad que se comunica ("quien"); el localizador expresa la localización de la entidad ("dónde"). Las aplicaciones usan direcciones visibles externamente que contienen el identificador. Cuando se envía un paquete, se hace una traducción que sobreescribe los primeros 64 bits de la dirección con el localizador. El paquete puede entonces ser redirigido por la red al host donde esté ubicada la entidad. El receptor hace la traducción inversa de manera que la aplicación vea la dirección original, sin traducir. <br />
<br />Esta característica se configura con el comando "ip -6 route", usando la opción "encap ila<locator> <locator>", donde <locator> es el valor a configurar en el localizador de destino del paquete, ej. <i><locator>ip -6 route add 3333:0:0:1:5555:0:1:0/128 encap ila 2001:0:0:1 via 2401:db00:20:911a:face:0:25:0 </locator></i><locator>configurará una ruta donde 333:0:0:1 será sobreescrito por 2001:0:0:1</locator></locator></locator></locator><br />
<br />
<locator><locator><b>· Túneles de red ligeros</b> </locator></locator><br />
<locator><locator></locator></locator><br /><locator><locator></locator></locator><locator><locator>Esta versión proporciona infraestructura para soportar túneles ligeros tales como túneles ip sobre MPLS. Permite una encapsulación escalable sin la sobrecarga de un netdevice completo. Para más información, leer este artículo de LWN</locator></locator> <a class="external" href="https://lwn.net/Articles/657012/">Identifier locator addressing</a>, o estas diapositivas <a class="external" href="http://vger.kernel.org/netconf2015Herbert-ILA.pdf">netconf2015Herbert-ILA.pdf</a><br />
<locator><locator><br />iproute2 ha sido extendido con dos nuevos casos: VXLAN: ip route add 40.1.1.1/32 encap vxlan id 10 dst 50.1.1.2 dev vxlan0; MPLS: ip route add 10.1.1.0/30 encap mpls 200 via inet 10.1.1.1 dev swp1<br /> <br /><b>· Soporte de Virtual Routing and Forwarding (Lite)</b></locator></locator><br />
<locator><locator><b> </b><br />Esta versión añade soporte de Virtual Routing and Forwarding (VRF), que, combinado con reglas ip, proporciona la abilidad de crear enrutados virtuales y dominios de reenvío (VRFs, o más bien <a href="https://en.wikipedia.org/wiki/Virtual_routing_and_forwarding#Simple_implementation">VRF-lite</a> para ser más específico). Para más información, leer la documentación en <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/plain/Documentation/networking/vrf.txt?id=562d897d15a6e2bab3cc9b4c172286b612834fe8">Documentation/networking/vrf.txt</a> </locator></locator><br />
<br />
Estas son las novedades principales de este kernel. Como siempre, pueden encontrar la lista completa, y en inglés, en <a href="http://kernelnewbies.org/Linux_4.3">esta página</a>.
Diegohttp://www.blogger.com/profile/18081775339476161685noreply@blogger.com0tag:blogger.com,1999:blog-7974522.post-12349010386059548162016-05-16T19:52:00.001+02:002016-05-16T19:52:30.438+02:00Las novedades de Linux 4.6Ya se <a href="https://lkml.org/lkml/2016/3/14/50">ha anunciado</a> la versión 4.6 de Linux. Esta versión añade soporte para USB 3.1 SuperSpeedPlus (10 Gbps), un nuevo sistema de archivos distribuido OrangeFS, una implementación del "OOM killer" más fiable, soporte para una característica de CPUs Intel llamada "memory protection keys", un sistema para implementar más fácilmente protocolos de capa de aplicación (nivel 7 OSI), soporte para cifrado a nivel de MAC 802.1AE (conocido como MACsec), soporte para la versión V del protocolo BATMAN, un chequeador de inodos online en OCFS2, soporte de diferentes espacios de nombre en los cgroups, soporte del layout SCSI en pNFS, y muchas otras mejoras y nuevos controladores. La lista completa de cambios, en inglés, puede <a href="http://kernelnewbies.org/Linux_4.6">encontrarse aquí</a>, como siempre.<br />
<br />
<br /><b>· Soporte de USB 3.1 SuperSpeedPlus (10Gbps)</b> <br />
La especificación de USB 3.1 incluye un nuevo protocolo SuperSpeedPlus que soporta velocidades de hasta 10 Gbps. Los dispositivos que utilizan este nuevo protocolo son apodados como dispositivos USB 3.1 Gen2 (nótese que SuperSpeedPlus no es lo mismo que Type-C)<br />
<br />
Esta versión añade soporte de la velocidad de 10 Gbps de USB 3.1 SuperSpeedPlus para el subsistema USB y el controlador host xHCI, lo cual significa que un dispositivo de almacenamiento USB 3.1 conectado a un host xHCI USB 3.1 debería poder alcanzar la velocidad de 10 Gbps.<br />
<br />
<b>· Mejora de la fiabilidad del asesino OOM</b><br />
<br />En anteriores versiones, el asesino OOM (que intenta matar un proceso cuando el sistema se queda sin memoria) intentaba matar un proceso con la esperanza de que acabase en un tiempo razonable y liberase su memoria. En la práctica, se ha demostrado que es fácil crear situaciones en las que esa asunción sea errónea, y el proceso elegido para ser eliminado tarde mucho tiempo porque ha sido bloqueado por otro proceso que está, a su vez, esperando a que se libere memoria. Esta versión añade un thread de kernel especializado, oom_reaper, que intenta liberar memoria librándose por adelantado de la memoria anónima o enviada al swap de la víctima, bajo la asunción de que esa memoria no será utilizada posteriormente.<br />
<br />
<b>· Soporte de Intel Memory Protection keys</b><br /><br />Esta versión añade soporte para una característica de hardware para la protección de memoria, que estará disponible en futuras CPUs Intel: protection keys. Protection keys permite insertar en las entradas de la tabla de páginas una serie de máscaras de protección configurables. En lugar de tener en la tabla de páginas una protección fija para una página determinada (que requiere una llamada al sistema y debe cambiar los permisos una vez por cada página), el usuario puede definir unas pocas áreas de memoria. Luego, el espacio de usuario puede manipular un nuevo registro (PKRU, individual para cada proceso/thread) donde se pueden asignar a cada área de memoria dos bits separados: Desactivar Acceso y Desactivar Escritura. De ese modo, con la sola escritura en ese registro, se puede cambiar la protección de enormes porciones de memoria, sin tener que cambiar los permisos de cada una de las páginas.<br />
<br />
También permite un control más preciso de los permisos de la MMU: Por ejemplo, el bit para desactivar la ejecución es distinto del bit para desactivar la lectura. Esta versión añade soporte para cambiar esos bits, y además añade una API para poder hacer uso de las <i>protection keys.</i> Si un programa en espacio de usuario hace la llamada <i>mmap (..., PROT_EXEC)</i> o <i>mprotect(ptr, sz, PROT_EXEC)</i>, (nótese el PROT_EXEC sólo, sin PROT_READ/WRITE), el kernel notará este caso especial, y activará una <i>protection key</i> en este rango de memoria, y cambiará el contenido del registro PKRU. De ese modo, con las <i>protection keys</i> el kernel puede implementar un "verdadero" PROT_EXEC: código que puede ser ejecutado, pero no leído, lo cual es una pequeña ventaja de seguridad (pero téngase en cuenta que el código malicioso también puede manipular el registro PKRU). En el futuro, habrá mejoras en la implementación de esta caraterística y nuevas APIs de más alto nivel.<br />
<br />
<b>· OrangeFS, un nuevo sistema de archivos distribuido</b> <br />
<br />OrangeFS es un sistema de almacenamiento paralelo, originalmente llamado PVFS y desarrollado en 1993 como parte de una beca de la NASA para estudiar los patrones de E/S de programas paralelos. Es ideal para solucionar los problemas de gran almacenamiento que se encuentran en entornos de HPC, BigData, Streaming de Video, Genómica, Bioinformática. OrangeFS puede ser accedido a través de utilidades del sistema, librerías, MPI-IO y puede ser utilizado por el ecosistema Hadoop como alternativa al sistema de archivos HDFS.<br />
<br />
Las aplicaciones a menudo no requieren que OrangeFS esté montado en el VFS, pero el cliente del kernel de OrangeFS permite montarlos. El cliente del kernel se comunica con un demonio en espacio de usuario que a su vez se comunica con el demonio-servidor de OrangeFS que implementa el sistema de archivos. El demonio-servidor no tiene por qué estar ejecutándose en el mismo sistema que el cliente del kernel. Los sistemas de archivo OrangeFS también pueden montarse con FUSE.<br /><br />
<b>· Multiplexor de conexiones del kernel, una herramienta para acelerar protocolos de capa de aplicación </b> <br />
<br />Esta versión añade el "Kernel Connection Multiplexor" o KCM, un sistema que proporciona una interfaz basada en mensajes sobre TCP para acelerar protocolos de la capa de aplicación. La motivación que tiene procede de la observación de que aunque TCP es un protocolo de transporte orientado a los streams de bytes, sin concepto de límites entre mensajes, un caso de uso común es la implementación de protocolos en la capa de aplicación dividido en mensajes, que se ejecuta sobre TCP. La mayor parte de pilas TCP ofrecen APIs de streams de bytes, lo cual fuerza a las aplicaciones a gestionar la delineación de mensajes, la atomicidad del envío y recepción de los mensajes, y balanceo de carga.<br />
<br />Con KCM una aplicación puede enviar y recibir eficientemente mensajes de un protocolo de la capa de aplicación sobre TCP. EL kernel proporciona la seguridad necesaria de que el mensaje será recibido y enviado atómicamente. Esto libera a la aplicación de buena parte del tedio de tener que mapear un protocolo basado en mensajes a un stream TCP. Para delinear el límite de los mensajes en el stream TCP, el kernel implementa un parseador de mensajes basado en BPF. Casi todos los protocolos de aplicación son parseables de esta manera, de modo que KCM debería ser usable por un amplio rango de aplicaciones.<br />
<br />
<b>· Cifrado a nivel de MAC 802.1AE (MACsec)</b> <br />
<br />Esta versión añade soporte para MACsec IEEE 802.1AE, un estandar que proporciona cifrado sobre ethernet. Cifra y autentifica todo el tráfico en una red LAN con GCM-AES-128. Puede proteger el tráfico DHCP y las VLANs y prevenir la manipulación de cabeceras de ethernet. MACSex está diseñado para ser utilizado con la extensión al protocolo 802.1X MACsec Key Agreement, que proporciona un mecanismo para la distribución de claves a los nodos, pero también puede utilizarse con claves estáticas configuradas manualmente por el administrador.<br />
<br />
<b>· Soporte para el protocolo V de BATMAN</b><br /><br />B.A.T.M.A.N. (Better Approach To Mobile Adhoc Networking) añade en esta versión soporte para el <a href="https://www.open-mesh.org/projects/batman-adv/wiki/BATMAN_V">protocolo V</a>, sucesor del protocolo IV. El nuevo protocolo divide el protocolo OGM en dos subcomponentes: <a href="https://www.open-mesh.org/projects/batman-adv/wiki/ELP">ELP</a> (Echo Location Protocol), que se ocupa del descubrimiento de nuevos nodos y estimación de la calidad de los enlaces; y un nuevo protocolo OGM, <a href="https://www.open-mesh.org/projects/batman-adv/wiki/OGMv2">OGMv2</a>, que implementa el algoritmo que difunde las métricas a lo largo de la red y computa las rutas óptimas. El cambio más importante introducido en esta versión del protocolo es la nueva métrica: Ya no se basará en la pérdida de paquetes, sino en la estimación del ancho de banda.<br />
<br />
<b>· dma-buf: una nueva ioctl para gestionar la coherencia entre la GPU y la CPU</b> <br />
<br />Los programas pueden necesitar algún tipo de mecanismo de gestión de la coherencia cuando tanto la CPU como la GPU están accediendo a recursos dma-buf simultáneamente. Para resolver este problema se ha añadido la ioctl DMA_BUF_IOCTL_SYNC, que permite manejar esos problemas de coherencia.<br />
<br />
<b>· Chequeador de inodos online para OCFS2</b> <br />
<br />OCFS2 a menudo es utilizado en sistemas de alta disponibilidad. OCFS2 suele remontar automáticamente el sistema de archivos al modo sólo-lectura cuando se encuentra un error, pero esta acción disminuye la disponibilidad, y no siempre es necesario. Existe una opción de montaje (errors=continue) que permite evitar ese montaje a sólo-lectura: sólo se devuelve -EIO al proceso que causó el error y se reporta el número de inodo problemático en el dmesg. Esta versión añade un chequeador de inodos muy simple en el kernel que puede utilizarse para comprobar y resetear el inodo. Nótese que esta característica está dirigida para problemas muy pequeños que puedan entorpecer las operaciones diarias de un cluster, no está dirigido a comprobaciones complejas, que deben seguir utilizando el fsck offline.<br />
<br />
<b>· Soporte para diferentes espacios de nombre en los cgroups</b> <br />
<br />Esta versión añade soporte para diferentes espacios de nombre en los cgroups, lo cual proporciona un mecanismo para virtualizar el contenido del archivo /proc/$PID/cgroup y de los montajes de cgroups. Se ha añadido una nueva bandera a clone(2) y unshare(2), CLONE_NEWCGROUP, que permite crear un nuevo espacio de nombres de cgroup. Para un contenedor correctamente configurado, esto permite a las herramientas de contenedores (libcontainer, lxc, lmctfy, etc) crear contenedores virtualizados que no revelen información crítica sobre otras jerarquías cgroup del sistema.<br />
<br />
<b>· Soporte del layout SCSI para pNFS</b><br />
<br />Esta versión añade soporte en pNFS (parallel NFS, disponible en NFS v4.1) para layouts SCSI en el servidor NFS de Linux. Con los layouts SCSI, el servidor NFS actua como un Servidor de Metadatos para pNFS, que además de gestionar todo el acceso a metadatos de la exportación NFS, también ofrece layouts al cliente de manera que los clientes puedan acceder los LUNs SCSI. Para más detalles ver <a href="https://tools.ietf.org/html/draft-ietf-nfsv4-scsi-layout-05">draft-ietf-nfsv4-scsi-layout</a><br />
<br />
Estas son las novedades principales de este kernel. Como siempre, pueden encontrar la lista completa, y en inglés, en <a href="http://kernelnewbies.org/Linux_4.6">esta página</a>.
Diegohttp://www.blogger.com/profile/18081775339476161685noreply@blogger.com0tag:blogger.com,1999:blog-7974522.post-22934306924467606392016-04-01T16:57:00.003+02:002016-04-01T16:57:35.556+02:00Las novedades de Linux 4.1(Nota: aunque con un retraso enorme, aquí va este post)<br />
<br />
Ya se <a href="https://lkml.org/lkml/2015/6/22/8">ha anunciado</a> la
versión 4.1 de Linux. Esta versión añade soporte de cifrado integrado en Ext4, soporte experimental de arrays RAID compartidos en clúster, un nuevo target del device mapper que permite mantener un registro de todas las escrituras hechas a un dispositivo y que permite reproducirlas, un driver que convierte la memoria de sistemas con memoria persistente en un dispositivo de bloques, posibilidad de desactivar el soporte multiusuario, soporte para el <i>Multiprotocol
Label Switching</i> que permite enrutar paquetes basándose en etiquetas de ruta en lugar de direcciones de red, capacidad de asociar programas BPF a sondas kprobes, soporte de ACPI en la arquitectura ARM64, y un driver GEM virtual que permite construir mejores rasterizadores por software. También hay nuevos drivers y muchas pequeñas mejoras. La lista completa de cambios, en inglés, puede <a href="http://kernelnewbies.org/Linux_4.1">encontrarse aquí</a>, como siempre.<br />
<br />
<br />
<b>· Soporte de cifrado en Ext4</b><br />
<br />
Linux ya proporciona sistemas para cifrar archivos, tales como dm-crypt o ecryptfs, pero tienen ciertos costes de rendimiento y consumo de memoria. En esta versión, el sistema de archivos Ext4 añade soporte nativo para cifrado: tanto los datos como los nombres de los archivos pueden ser cifrados con una clave proporcionada por el usuario. La clave se utiliza para los archivos de un directorio y todos sus subdirectorios. Cuando haya que leer un archivo, si no se ha proporcionado previamente una clave válida, sólo se podrá leer los nombres de archivo cifrados, pero pero no los descifrados, y los datos cifrados no se podrán leer.<br />
<br />
Para usar esta característica, se necesitan e2fsprogs versión 1.43 y el software keyutils. <a href="http://askubuntu.com/questions/643577/how-to-create-ext4-encrypted-partition-on-ubuntu-15-04-with-new-4-1-kernel">Aquí</a> hay un pequeño howto. Para detalles sobre el diseño interno, ver <a href="https://docs.google.com/document/d/1ft26lUQyuSpiu6VleP70_npaWdRfXFoNnB8JYnykNTg">aquí</a>. Artículo de LWN recomendado: <a href="http://lwn.net/Articles/639427/">Ext4 encryption</a> <br />
<br />
<b>· Soporte experimental de clustering en MD</b><br />
<br />
Esta versión añade soporte experimental de clústering en <a href="http://linux.die.net/man/4/md">MD</a> (Linux software RAID). Un Cluster MDes un dispositivo compartido RAID para un clúster. Permite bloqueos y sincronización a través de múltiples sistemas de un clúster, de modo que todos los nodos del clúster pueden acceder al dispositivo MD simultáneamente, proporcionando la redundancia (y uptime) del RAID a todos los nodos del clúster. En esta versión, la implementación está limitada a RAID1, pero en el futuro podría extenderse a otros niveles RAID. El código en esta versión es altamente experimental. Howto: <a href="http://marc.info/?l=linux-raid&m=141935561418770&w=2">howto</a><a href="https://git.kernel.org/torvalds/c/b8d834488fd7c0c5a79cd2bab112c37a3d3292b9"></a> <br />
<br /><b>· Device mapper: nuevo target que guarda un registro de las escrituras</b><br />
<br />
En esta versión, el device mapper introduce un nuevo target que permite hacer un registro de todas las operaciones de escritura, y guardar ese registro en un dispositivo separado, de modo que puedan reproducirse las operaciones a posteriori. La motivación de esta funcionalidad es proporcionar a los desarrolladores una herramienta para verificar el sistema de archivos en varios puntos de la vida de un sistema de archivos, permitiéndoles reproducir el registro hasta un punto concreto.<br />
<br />
<b>· Soporte de monousuario</b> <br />
<br />Puede parecer extraño que un sistema multi-usuario como Linux quiera adoptar una funcionalidad que es una regresión al pasado, tal y como lo es la eliminación de la protección multi-usuario. Pero resulta que los dispositivos embebidos quieren hacer Linux lo más pequeño que sea posible, y no necesitan las capacidades multi-usuario. En esta versión, es posible configurar el kernel para que el UID y GID de todos los procesos sean cero (root) en todos los casos. Con esto, se ahorra la compilación de 25 KB de código en una configuración defconfig. Artículo LWN recomendado: <a href="http://lwn.net/Articles/631853/">Linux as a single-user system</a> <br />
<br />
<b>· Driver virtual GEM para implementar mejores rasterizadores por software</b><br />
<br />El driver vGEM proporciona un GEM (graphics memory manager) que puede ser utilizado por el renderizador por software de la librería MESA para mejorar el rendimiento.<br />
<br />
<b>· Dispositivo de bloques para memoria persistente</b> <br />
<br />Hay nuevos tipos de memoria que pueden ser accedidas casi tan rápido como la RAM, pero que no pierden los datos cuando se apaga el equipo. Este tipo de memoria se llama memoria persistente. En esta versión, Linux incluye PMEM, un driver que representa un rango de memoria reservado como un dispositivo de bloques, que puede ser utilizado posteriormente por sistemas de archivo. Artículo recomendado de LWN: <a href="http://lwn.net/Articles/640113/">Persistent memory support progress</a> <br />
<br />
<b>· Multiprotocol Label Switching</b> <br />
<br />Esta versión añade soporte para <a href="https://en.wikipedia.org/wiki/Multiprotocol_Label_Switching#Deployment">Multiprotocol Label Switching (MPLS)</a>. MPLS es un transporte de red escalable e independiente de protocolo, que dirige los datos de un nodo al siguiente basándose en etiquetas cortas en lugar de direcciones de red, de modo que se evitan las búsquedas complejas en la tabla de enrutado, porque las decisiones sobre el redireccionamiento de paquetes se toman en base de los contenidos de una etiqueta, sin necesidad de examinar el paquete. Las etiquetas identifican enlaces virtuales (rutas) entre nodos distantes, en lugar de destinos. MPLS puede encapsular paquetes de varios protocolos de red.<br />
<br />
<b>· Los programas BPF pueden ser asociados a sondas kprobes</b><br />
<br />En esta versión, Linux permite asociar pequeños programas BPF a sondas kprobes, proporcionando de este modo una manera segura de ejecutar programas BPF, sin riesgos para la seguridad o la estabilidad. Esto permite construir, en un kernel en ejecución, instrumentación definida por el usuario que no puede colgar o interferir con el kernel. En esta versión, sólo se permite el uso por root.<br />
<br />
<b>· Soporte de ACPI para la arquitectura ARM64</b><br />
<br />
Durante mucho tiempo, ACPI ha sido una característica exclusiva de sistemas x86 (e Itanium). A pesar de las controversias, algunas partes del mundo ARM han empezado a utilizar el estándar ACPI. Esta versión añade soporte preliminar de ACPI 5.1 a la arquitectura arm64.<br />
<br />
<br />
<br />
Estas son las novedades principales de este kernel. Como siempre, pueden encontrar la lista completa, y en inglés, en <a href="http://kernelnewbies.org/Linux_4.1">esta página</a>.
Diegohttp://www.blogger.com/profile/18081775339476161685noreply@blogger.com1tag:blogger.com,1999:blog-7974522.post-58247574087260810052016-03-31T20:23:00.001+02:002016-03-31T20:26:40.249+02:00 Las novedades de Linux 4.2(Nota: aunque con un retraso enorme de medio año, aquí va este post)<br />
<br />
Ya se <a href="https://lkml.org/lkml/2015/8/30/96">ha anunciado</a> la versión 4.2 de Linux. Esta versión añade el driver amdgpu para GPUs de AMD, un driver virtio para la virtualización de GPU, la nueva API gráfica "atomic modesetting" ya es estable, soporte para usar más de un módulo de seguridad al mismo tiempo, una implementación de spinlock más rápida y escalable, soporte de control de writeback dentro de los cgroups, y la reintroducción del soporte para la arquitectura H3/800. También se han incluido drivers nuevos y muchas otras mejoras y pequeños cambios. La lista completa de cambios, en inglés, puede <a href="http://kernelnewbies.org/Linux_4.2">encontrarse aquí</a>, como siempre.<br />
<br />
<br />
<b>· Nuevo driver amdgpu para hardware AMD Radeon moderno</b><br />
<br />
Esta versión incluye el driver amdgpu, un nuevo driver para asics AMD VI+. Actualmente soporta Tonga, Iceland y Carrizo, y también contiene una opción para soportar experimentalmente partes CI. Toda la funcionalidad importante está soportada. La gestión energética funciona en Carrizo, pero todavía está en desarrollo para Tonga e Iceland.<br />
<br />
Este driver es un punto de partida de cero de AMD para centrar en él su <a href="https://en.wikipedia.org/wiki/GPUOpen">nueva estrategia</a> de apuesta por el software libre: Su propósito es que el único driver para gráficos AMD sea éste; la funcionalidad privativa que existe actualmente en el driver Catalyst será portada al driver o se ejecutará como un binario que se ejecute en espacio de usuario e interactúe con el driver.<br />
<br />
<b>· Driver virtio para GPUs </b><br />
Los drivers <a href="http://wiki.libvirt.org/page/Virtio">virtio</a> son "falsos" drivers diseñados para hacer la comunicación entre huéspedes y anfitriones de virtualización más eficiente. Emular el hardware real es complejo e ineficiente, estos drivers en cambio son conscientes de estar ejecutándose en entornos virtualizados, y ofrecen canales para el intercambio de datos simples y rápidos.<br />
<br />
En esta versión se incluye un driver para GPUs virtuales. Puede ser utilizado en máquinas virtuales de QEMU. Por ahora sólo soporta kernel-modesetting; el driver modesetting de X.org es capaz de gestionar el dispositivo perfectamente, y también está disponible el framebuffer para fbcon. Los parches para el soporte en QEMU están siendo revisados. La versión inicial sólo tiene soporta para 2D; el soporte 3D requiere más trabajo en QEMU y será añadido más tarde.<br />
<br />
<b>· La API atomic modesetting activada por defecto</b><br />
<br />
Esta versión por fin completa la nueva API atomic modesetting, y la activa por defecto (hasta ahora era experimental y requería ser activada manualmente). Esta API es necesaria para implementar mejor los sistemas gráficos modernos; para más detalles sobre esta API y por qué es necesaria, se recomienda leer estos artículos de LWN: <a href="https://lwn.net/Articles/653071/">Atomic mode setting design overview, parte 1</a>, y <a href="https://lwn.net/Articles/653466/">parte 2</a> <br />
<br />
<b>· Apilado de módulos de seguridad</b><br />
<br />
Hay varios módulos de seguridad disponibles en Linux, pero sólo se puede usar uno al mismo tiempo. Durante muchísimo tiempo, ha habido desarrolladores que han querido poder utilizar más de un módulo de seguridad al mismo tiempo ("stacking", es decir "apilando" otro módulo tras el primero). Esta versión añade soporte para el "apilado" de módulos de seguridad. Para más detalles, léase <a href="https://lwn.net/Articles/635771/">Progress in security module stacking</a> <br />
<br />
<b>· Una nueva implementación de spinlocks</b><br />
<br />
Esta versión añade soporte en la arquitectura x86 para un nuevo tipo de spinlocks basados en una cola. Esta nueva implementación es capaz de reemplazar la actual implementación por defecto de spinlocks basado en "tickets", sin incrementar el tamaño de la estructura de datos del spinlock. <br />
<br />
Este nuevo spinlock tiene un rendimiento ligeramente lejor que el "ticket" en caso de que no haya contención, y su rendimiento puede ser mucho mejor cuando hay contención moderada o alta. Es especialmente útil para máquinas NUMA con al menos 2 sockets; aunque incluso con sólo 2 sockets puede haber mejoras significativas, dependiendo del trabajo a realizar. También puede mejorar el rendimiento de un test de estrés intensivo de E/S e interrupciones hasta un 20%. Para más detalles, leer <a href="https://lwn.net/Articles/590243/">MCS locks and qspinlocks.</a> <br />
<br />
<b>· Soporte de control de writeback dentro de un cgroup</b><br />
<br />
Linux es capaz de limitar a los procesos que están intentando escribir muchas páginas de memoria al disco (writeback). Pero este control es global, y no permite un control personalizado en los cgroups. Esta versión añade soporte para control de writeback a los procesos de un cgroup. Para más detalles, ver <a href="http://lwn.net/Articles/648292/">Writeback and control groups</a> <br />
<br />
<b>· Reintroducción de la arquitectura H8/300</b><br />
<br />
Linux añadió soporte para la <a href="http://sg.renesas.com/products/mpumcu/h8/h8300/index.jsp">arquitectura H8/300</a> en Linux <a href="https://lwn.net/Articles/29489/">2.5.68</a>. Pero fue eliminada <a href="http://kernelnewbies.org/Linux_3.13-DriversArch#head-822cd1ebdfb3ba567aae68fc49dd9ee2244eeb2f"> en Linux 3.13</a> por falta de mantenimiento. <br />
<br />
En esta versión, se ha vuelto a implementar el soporte para esta arquitectura.<br />
<br />
<br />
<br />
Estas son las novedades principales de este kernel. Como siempre, pueden encontrar la lista completa, y en inglés, en <a href="http://kernelnewbies.org/Linux_4.2">esta página</a>.
Diegohttp://www.blogger.com/profile/18081775339476161685noreply@blogger.com1tag:blogger.com,1999:blog-7974522.post-45885006925852699552016-03-14T07:58:00.001+01:002016-03-14T07:58:08.018+01:00 Las novedades de Linux 4.5Ya se <a href="https://lkml.org/lkml/2016/3/14/50">ha anunciado</a> la versión 4.5 de Linux. Esta versión añade una nueva llamada al sistema, copy_file_range(2), que permite copiar archivos sin el coste de transferir los datos a través del espacio de usuario; soporte experimental de la gestión de energía Powerplay en GPUs Radeon modernas; mejoras de escalabilidad en la gestión del espacio libre de Btrfs; soporte para el Undefined Behavior Sanitizer de GCC (-fsanitize=undefined); soporte para Forwarded Error Correction en el objetivo verity del device-mapper, soporte para la bandera MADV_FREE en madvise(); la nueva jerarquía unificada de cgroup ya se considera estable; mejoras de escalabilidad en sockets UDP que hacen uso de SO_REUSEPORT; y mejoras de escalabilidad para epoll. También se han incluido drivers nuevos y muchas otras mejoras y pequeños cambios. La lista completa de cambios, en inglés, puede <a href="http://kernelnewbies.org/Linux_4.5">encontrarse aquí</a>, como siempre.<br />
<br />
<br />
<b>· Copias más rápidas con la llamada al sistema copy_file_range(2)</b><br />
<br />
Copiar un archivo consiste en leer datos de un archivo a la memoria de un proceso, y luego copiar los datos de esa memoria al archivo destino. No hay nada malo con esta manera de hacer las cosas, pero requiere hacer copias extra de los datos al copiarlos a/desde la memoria del proceso. En esta versión Linux añade una nueva llamada al sistema, copy_file_range(2), que permite copiar un rango de datos de un archivo a otro, evitando el coste mencionado de transferir los datos del kernel al proceso y luego de nuevo al kernel.<br />
<br />
Esta llamada al sistema sólo es ligeramente más rápida que cp, porque el coste de hacer las copias apenas es nada, comparado con el tiempo que toma hacer la E/S, pero hay algunos casos en los que puede ayudar mucho. En sistemas de archivos de red, como NFS, copiar los datos implica enviar los datos del servidor al cliente a través de la red, y luego enviarlos de nuevo del cliente al nuevo archivo en el servidor. Pero con copy_file_range(2), el cliente puede ordenar al servidor NFS que copie un rango de datos específico de un archivo a otro, sin transferir los datos a través de la red (para NFS, esto requiere también el soporte de la característica "copia del lado del servidor, <a href="https://tools.ietf.org/html/draft-ietf-nfsv4-minorversion2-41#section-4">presente en el próximo NFSv4.2</a>, y también soportado experimentalmente en esta versión). En próximas versiones, los sistemas de archivos locales como Btrfs, o algunos dispositivos de almacenamiento especializados, podrían usar esta llamada al sistema para optimizar la copia de datos, o se podrían eliminar algunas de las limitaciones actuales (la copia de datos está limitada a archivos que se encuentren en la misma montura y superbloque, y que las copias no sean entre partes del mismo archivo)<br />
<br />
<b>· Gestión de energía PowerPlay experimental en el driver amdgpu</b> <br />
<br />
Las GPUs modernas arrancan en modo de bajo consumo y rendimiento, y necesitan alterar dinámicamente su frecuencia para funcionar en los modos que proporcionan el mejor rendimiento. Pero eso no puede hacerse sin gestión de energía. Esta versión incorpora soporte de Powerplay en el driver amdgpu para GPUs Tonga y Fiji, y APUs integradas Carrizo y Stoney.<br />
<br />
Powerplay es el nombre dado por AMD al sistema de gestión de energía presente en varias de sus GPUs y APUs y soportado en el driver propietario Catalyst, y ahora aspira a reemplazar la actual gestión de energía del driver amdgpu. En las GPUs soportadas el rendimiento será mucho más alto.<br />
<br />
Powerplay no está activado por defecto en todos los tipos de hardware soportado debido a su carácter experimental, en esos casos puede intentar forzarse su uso con la opción del kernel "amdgpu.powerplay=1".<br />
<br />
<b>· Mejoras de escalabilidad en la gestión del espacio libre de Btrfs</b> <br />
<br />
Los sistemas de archivos necesitan mantener un registro de los bloques que están en uso y de los que no. También necesitan almacenar información sobre el espacio libre en algún lado, porque regenerarlo de cero cuesta demasiado. Btrfs ha tenido la capacidad de almacenar un caché del espacio libre <a href="http://kernelnewbies.org/Linux_2_6_37#head-73fc3db571309a002aad2f56e930923422cff5d2">desde 2.6.37</a>, pero la implementación se ha convertido en un cuello de botella de escalabilidad en los sistemas de archivos grandes (+30T) y ocupados. <br />
<br />
Esta versión incluye una nueva y experimental implementación del caché de espacio libre, que es más ligero y resuelve los problemas de escalabilidad citados. Este nuevo sistema es experimental, y no está activado por defecto. Puede ser activado con la opción de montaje -o space_cache=v2. La primera vez que se utilice esta opción, se creará el nuevo caché de espacio libre y se activará una bandera de sólo lectura (los kernels antiguos podrán leer, pero no escribir, al sistema de archivos). Es posible revertir el cambio y volver al caché antiguo (y eliminar la bandera de sólo lectura) utilizando la opción de montaje -o clear_cache,space_cache=v1.<br />
<br />
<br />
<b>· Soporte para el Undefined Behaviour Sanitizer de GCC (-fsanitize=undefined)</b> <br />
<br />
UBSAN (Undefined Behaviour SANitizer) es una herramienta de depuración disponible en GCC a partir de la versión 4.9 (ver <a href="https://gcc.gnu.org/onlinedocs/gcc-4.9.0/gcc/Debugging-Options.html">-fsanitize=undefined documentation</a>). Se trata de una funcionalidad que inserta código durante la compilación que hace comprobaciones en tiempo de ejecución para detectar situaciones que podrían causar comportamientos indefinidos. <a href="https://es.wikipedia.org/wiki/Comportamiento_indefinido">Comportamiento indefinido</a> significa que las semánticas de ciertas operaciones no están definidas y el compilador asume que esas operaciones no se dan y que el programador se preocupará de evitarlas, pero de ocurrir la aplicación puede producir resultados equivocados, estrellarse, o incluso producir agujeros de seguridad; ejemplos de comportamientos indefinidos son el uso de una variable no estática antes de ser inicializada, división de un entero por cero, desbordamiento de enteros con signo, desreferenciación de punteros NULL, etc.<br />
<br />
<br />
En esta versión, Linux soporte la posibilidad de compilar el kernel con la funcionalidad Undefined Behavior Sanitizer activada, con las opciones de -fsanitize: shift, integer-divide-by-zero, unreachable, vla-bound, null, signed-integer-overflow, bounds, object-size, returns-nonnull-attribute, bool, enum y, opcionalmente, alignment. La mayor parte del trabajo lo hace el compilador, el kernel se limita a mostrar los errores.<br />
<br />
<b>· Soporte de Forwarded Error Correction en el target verity del device-mapper</b><br />
<br />
El target "verity" del device-mapper, utilizado por plataformas populares como <a href="https://source.android.com/security/verifiedboot/">Android</a> o Netflix, fue incluido <a href="http://kernelnewbies.org/Linux_3.4#head-011d0bd1a20451b0e374283b36a71d8e8f5b7ae1">en Linux 3.4</a>, y permite comprobar que un sistema de archivos no ha sido modificado, comprobando cada lectura del sistema de archivos con una lista de hashes criptográficos. <br />
<br />
Esta versión añade soporte de <a href="https://en.wikipedia.org/wiki/Forward_error_correction">Forward Error Correction</a> para el target verity. Esta característica hace posible recuperarse de varios bloques de datos corrompidos, utilizando unos bloques pre-generados de correción de errores, que no ocupan demasiado espacio y pueden ser utilizados para reconstruir los bloques dañados. Esta técnica, utilizada en DVDs, discos duros o transmisiones satélite, permitirá seguir utilizando un sistema de archivos de un target verity que esté ubicado en un medio de almacenamiento que esté ligeramente dañado.<br />
<br />
<b>· Añadir la bandera MADV_FREE a madvise(2)</b><br />
<br />
<a href="http://man7.org/linux/man-pages/man2/madvise.2.html">madvise(2)</a> es una llamada al sistema utilizada por los procesos para decirle al kernel cómo van a utilizar su memoria, permitiendo al kernel, de ese modo, optimizar la gestión de memoria de acuerdo con las pistas proporcionadas, para alcanzar un mejor rendimiento del sistema.<br />
<br />
Cuando una aplicación quiere decir al kernel que no va a utilizar un rango de memoria en un futuro cercano, puede usar la bandera MADV_DONTNEED, de manera que el kernel puede liberar los recursos de memoria asociados a ese rango. Los accesos subsiguientes tendrán éxito, pero sus consecuencia serán o bien recargar la memoria con datos del archivo mapeado, o páginas puestas a cero para los mapeados que no estén respaldados por archivos. Pero hay algunos tipos de aplicaciones (notablemente, asignadores de memoria de librerías) que pueden reusar ese rango de memoria, y MADV_DONTNEED fuerza a que incurran en el coste de hacer un fallo de página, asignación de una página, rellenarla con ceros, etc. Para evitar esa sobrecarga, otros sistemas operativos como los BSDs <a href="https://www.freebsd.org/cgi/man.cgi?query=madvise&sektion=2">han soportado MADV_FREE</a>, que simplemente marca las páginas como disponibles para ser liberadas, pero sin liberarlos inmediatamente, y por lo tanto permitiendo reusar la memoria en un corto espacio de tiempo sin incurrir en el coste de un fallo de página.<br />
<br />
<b>· Mejor escalabilidad multihilo en epoll</b> <br />
<br />
Cuando se añaden múltiples descriptores de archivo de <a href="http://man7.org/linux/man-pages/man7/epoll.7.html">epoll</a> a una sóla fuente de eventos compartida entre todos, se añaden de modo que un evento puede despertar a todos los descriptores de archivo de epoll, lo cual crea un problema de escalabilidad cuando se utilizan muchísimos descriptores de archivo desde muchos hilos. <br />
<br />
Esta versión añade una nueva bandera, EPOLLEXCLUSIVE, que puede pasarse como parte del argumento 'event' durante una operación EPOLL_CTL_ADD con <a href="http://man7.org/linux/man-pages/man2/epoll_ctl.2.html">epoll_ctl(2)</a>. Esta nueva bandera permite que las notificaciones de eventos no despierten a todos los descriptores de archivo. En una versión modificada de <a href="https://en.wikipedia.org/wiki/Enduro/X">Enduro/X</a>, el uso de la bandera 'EPOLLEXCLUSIVE' redujo la longitud de esta carga particular de 860s a 24s.<br />
<br />
<b>· La jerarquía unificada de cgroup se considera estable</b> <br />
<br />
cgroups, o grupos de control, son una característica <a href="http://kernelnewbies.org/Linux_2_6_24#head-5b7511c1e918963d347abc8ed4b75215877d3aa3">introducida en Linux 2.6.24</a> que permite asignar recursos (como tiempo de CPU, memoria, ancho de banda) entre grupos de procesos definidos por el usuario. En su primera implementatión, los cgroups permitían un número arbitrario de jerarquías de procesos y cada jerarquía podía albergar cualquier número de controladores. Este modo de operar proporcionaba mucha flexibilidad, pero en la práctica tenía una serie de problemas, así que en <a href="http://kernelnewbies.org/Linux_3.16#head-c8889cafd94fac58408ccc55a02589eda7608eb9">Linux 3.16</a> se incluyó una uneva <a href="http://lwn.net/Articles/601840/">jerarquía unificada</a>, pero experimental, y sólo disponible con la opción de montaje -o __DEVEL__sane_behavior. <br />
<br />
En esta versión, la jerarquía unificada ya se considera estable, y ya no se esconde tras esa opción de montaje especial. Puede ser montada con el tipo de archivo cgroup2 (desgraciadamente, el controlador de cpu no ha llegado a ser incluído en esta versión, sólo los controladores de memoria y E/S están disponibles). Para mas detalles sobre cgroup2 y una justificación detallada sobre la migración a la jerarquía unificada, ver la <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/cgroup-v2.txt%20Documentation/cgroup-v2.txt">documentación de cgroup2</a>.<br />
<br />
<b>· Mejoras de rendimiento para sockets UDP que usen SO_REUSEPORT</b> <br />
<br />
<a href="https://lwn.net/Articles/542629/">SO_REUSEPORT</a> es una opción de socket disponible <a href="http://kernelnewbies.org/Linux_3.9#head-7f858c19da75698842d3571a2424c9b62d3f5b0a">desde Linux 3.9</a> que permite que múltiples sockets de escucha se "enganchen" al mismo puerto. La motivación tras el desarrollo de SO_REUSEPORT serían casos de uso tales como un servidor web escuchando en el puerto 80, y ejecutando múltiples hilos, cada uno con su propio socket.<br />
<br />
En esta versión, Linux incluye dos optimizaciones para SO_REUSEPORT (en esta versión, sólo para sockets UDP): <br />
· Hay dos nuevas opciones de socket para sockets SO_REUSEPORT: SO_ATTACH_REUSEPORT_CBPF y SO_ATTACH_REUSEPORT_EBPF. Esas opciones permiten definir un programa BPF clásico o extendido, que defina cómo los paquetes se asignan a los sockets que están esperando en el grupo de sockets SO_REUSEPORT.<br />
· Búsqueda más rápida al seleccionar un socket SO_REUSEPORT para un paquete entrante. Anteriormente, el proceso de búsqueda necesitaba iterar por todos los sockets, en esta versión se puede encontrar un candidato mucho más rápido.<br />
<br />
<b>· Mejor gestión del uso de memoria de los sockets en el controlador de memoria</b> <br />
<br />
En anteriores versiones, los buffers de los sockets se contaban en el controlador de memoria de los cgroup por separado, sin ninguna presión que igualara entre la memoria anónima, el caché de páginas, y los buffers de sockets. Cuando se acababa la memoria de la reserva de buffers de socket, las asignaciones de buffers fallaban y el rendimiento de la red se hundía, al margen de que aun hubiera memoria disponible en el grupo o no. Del mismo modo, la memoria anónima u otros caches no podían hacer uso de la reserva para buffers de sockets que no estuviese siendo usada. Por esta razón, esta característica no podía ser usada con fiabilidad en muchas aplicaciones de la vida real.<br />
<br />
En esta versión, el nuevo controlador de memoria unificado tendrá en cuenta todos los tipos de memoria a su cargo. Cuando haya poca memoria, la VM reclamará y reducirá y presionará en cualquier consumidor de memoria. Cuando la VM tenga problemas liberando memoria, la pila de red detendrá los incrementos en los "transmit windows" del cgroup. Para evitar la gestión de memoria de los sockets de buffer, es posible usar la opción del kernel cgroup.memory=nosocket.<br />
<br />
<br />
<br />
Estas son las novedades principales de este kernel. Como siempre, pueden encontrar la lista completa, y en inglés, en <a href="http://kernelnewbies.org/Linux_4.5">esta página</a>.Diegohttp://www.blogger.com/profile/18081775339476161685noreply@blogger.com3tag:blogger.com,1999:blog-7974522.post-20429954349268456902016-01-19T17:04:00.001+01:002016-01-19T17:04:45.153+01:00Las novedades de Linux 4.4 Ya se <a href="https://lkml.org/lkml/2016/1/10/305">ha anunciado</a> la versión 4.4 de Linux. Esta versión añade soporte 3D para el driver de la GPU virtual, que permite usar la aceleración 3D de hardware en sistemas virtualizados; se añade también soporte de E/S directo y asíncrono en el dispositivo loop, lo cual ahorra memoria y mejora el rendimiento; se añade soporte para discos SSDs Open-Channel, que son SSDs que intentan compartir con el sistema operativo la responsabilidad de la FTL; la gestión de los "TCP listener" se hace ahora sin ningún tipo de bloqueo y permite que los servidores TCP sean más rápidos y mucho más escalables; journaling de RAID5 en la capa MD que permite solucionar el llamado "write hole"; los programas eBFP pueden ahora ser ejecutados por usuarios sin privilegios, pueden hacerse permanentes tras el fin de un proceso, y la utilidad perf ha añadido soporte para eBFP también; una nueva llamada de sistema mlock2() que permite bloquear la memoria añadida desde los fallos de página; y soporte de polling en dispositivos de bloques que mejora el rendimiento en los dispositivos de muy alto rendimiento. También se han incluido drivers nuevos y muchas otras mejoras y
pequeños cambios. La lista completa de cambios, en inglés, puede <a href="http://kernelnewbies.org/Linux_4.4">encontrarse aquí</a>, como siempre.<br /><br /><br /> <b>· Dispositivo loop más rápido y ligero con E/S Directa y Asíncrona</b><br /><br />
Esta versión incorpora soporte de E/S directa y asíncrona en el dispositivo de bloques loop. Esto tiene varias ventajas: se mejora el consumo de memoria porque se evita mantener un cache duplicado; y se mejora el rendimiento al evitarse cambios de contexto<br />
<br />
<b>· Soporte en el driver de GPU virtual</b><br />
<br />
virtio-gpu es un driver para huéspedes de virtualización que permite utilizar las capacidades gráficas del anfitrión eficientemente. En esta versión, se permite que el huésped utilice las capacidades de la GPU del anfitrión para acelerar los gráficos 3D. En la práctica, esto significa que un huésped virtualizado Linux puede ejecutar juegos OpenGL utilizando la GPU, como se muestra <a href="https://www.youtube.com/watch?v=ONFGnUaln-4">aquí</a> o <a href="https://www.youtube.com/watch?v=ZuuF092RDDc">aquí</a>. Se requiere el uso de <a href="http://wiki.qemu.org/ChangeLog/2.5#virtio">QEMU 2.5</a> o superior.<br />
<br />
<b>· LightNVM añade soporte para SSDs Open-Channel</b><br />
<br />
Los SSDs Open-Channel son dispositivos que comparten con el sistema operativo la responsabilidad de implementar y mantener las características que los SSDs implementan típicamente en el firmware, tales como la Flash Translation Layer (FTL), la gestión de bloques dañados, y unidades del hardware como el controlador flash, el controlador de la interfaz, y muchos chips flash. De este modo, los SSDs Open-Channel exponen un acceso directo al almacenamiento físico flash. <br /><br />LightNVM es una especificación que da soporte a SSDs Open-Channel. LightNVM permite al sistema gestionar la ubicación de los datos, la recolección de memoria y el paralelismo, mientras que otras características permanecen en control del hardware. Esta versión de Linux añade soporte para lightnvm y para NVMe.<br />
<br />
<b>· Gestión de TCP listeners sin bloqueos</b><br /><br /> En esta versión, y como resultado de un esfuerzo que empezó hace dos años, la implementación TCP ha sido reescrita para que no haya ningún bloqueo en las rutas más comunes del código que gestiona a los programas que hacen escuchas TCP. En pruebas, un servidor fue capaz de procesar 3.500.000 de paquetes SYN por segundo en un sólo listener y sin llegar a ocupar todo el tiempo de CPU, esto representa entre 2 y 3 órdenes de magnitud de lo que era posible previamente. SO_REUSEPORT también ha sido extendido para añadir afinidades de CPU/NUMA.<br />
<br />
<b>· Soporte de journalled RAID5 en MD</b><br /><br /> Esta versión añade soporte de RAID 5 journalled en la capa MD (RAID/LVM). Con un dispositivo de journal configurado (típicamente NVRAM o SSD), los datos y la paridad de un array RAID se escriben primero al journal, y luego al array. Si el sistema se bloquea, se pueden recuperar datos del log. Esto puede acelerar la resincronización RAID y resuelve el problema del "write hole" de RAID5 - un cuelgue durante el modo degradado no resultará en corrupción de datos. En futuras versión el journal será utilizado también para mejorar el rendimiento y la latencia.<br />
<br />
<b>· Programas eBPF sin privilegios + programas eBPF persistentes</b><br />
<br /> Programas eBPF sin privilegios<br /> Los programas eBPF consiguieron su propia llamada al sistema en <a href="http://kernelnewbies.org/Linux_3.18#head-ead251efb6bbdbe2922e7c6bd0c7b46342e03dad">Linux 3.18</a>, pero hasta ahora su uso había estado restringido a root, porque estos programas son peligrosos para la seguridad. Sin embargo, los programas eBPF son validados por el kernel, y en esta versión el verificador de programas eBPF ha sido mejorado y como resultado los usuarios sin privilegios pueden hacer uso de ellos (aunque sólo podrán construir programas tipo filtro de sockets, los programas que usen funciones de trazado o del control de tráfico de red requerirán root). esta característica puede ser desactivada con la sysctl kernel.unprivileged_bpf_disabled (una vez desactivada sólo root podrá usar programas eBPF, y la sysctl no podrá volver a cambiarse)<br />
<br />
Programas eBPF persistentes<br /> Esta versión añade soporte para mapas/programas eBPF "persistentes". El término "persistente" ha de entenderse como un mecanismo que permite que sobrevivan al fin del proceso que los crea. Hay usuarios eBPF que desean este tipo de comportamientos, por ejemplo el clasificador de tráfico <a href="http://man7.org/linux/man-pages/man8/tc.8.html">tc(8)</a>. Cuando tc hace uso de un objecto eBPF, nuevas invocaciones de tc no podrán reutilizarlo.<br />
<br /> Para solucionar ese problema, se ha añadido un sistema de archivos virtual que puede almacenar programas y mapas eBPF en /sys/fs/bpf/. Los objetos eBPF son creados mediante la llamada al sistema bpf() junto con una ruta y dos nuevos comandos (BPF_OBJ_PIN/BPF_OBJ_GET) que crean los archivos correspondientes en el sistema de archivos. Estos archivos pueden ser reutilizados posteriormente por otros procesos, a través también de bpf(2). <br /><br /><b>· Integración de perf y eBPF</b><br /><br />
En esta versión, los programas eBPF han sido integrados en perf. Cuando se pasa a perf un archivo .c eBPF (o uno .o compilado con el target "bpf" de clang) será compilado automáticamente, validado y cargado en el kernel, pudiendo ser utilizado posterioemente por perf trace y otras herramientas.<br />
<br />
Los usuarios pueden hacer uso de un filtro eBPF con comandos como: #<em> perf record --event ./hello_world.o ls; </em>y el programa eBPF será conectado a un evento perf que puede ser utilizado por el resto de herramientas.<br />
<br />
<b>· Soporte de polling para dispositivos de bloque</b><br /><br /> Esta versión añade soporte básico para hacer polling para que una petición de E/S concreta se complete, lo cual puede mejorar la latencia y el rendimiento en dispositivos muy rápidos. De momento, se soportan escrituras y lecturas síncronas con O_DIRECT. Este soporte es preliminar y sólo debe ser utilizado para pruebas, en próximas versiones se utilizarán estadísticas para hacer uso de este modo automáticamente. De momento, se añade un archivo en sysfs (io_poll) que controla si el polling está activado o no.<br />
<br />
<b>· Llamada al sistema mlock2() que permite a los usuarios bloquear memoria en fallos de página</b><br /><br /> mlock() permite a un usuario bloquear la memoria de un programa en la RAM, pero esto tiene como coste la necesidad de incluir en la RAM toda la memoria de una vez. Este comportamiento no es muy adecuado cuando se necesita usar mlock() con mapeados de archivos muy grandes: Por ejemplo, las aplicaciones sensibles con la seguridad que usan mlock() pueden verse forzadas a bloquear un búfer demasiado grande. O quizás un modelo gráfico gigantesco donde la ruta de un grafo no es conocida hasta el tiempo de ejecución, en lugar de bloquear en memoria sólo las partes utilizadas están forzadas a bloquear todo el grafo o ir bloqueando página tras página a medida que van siendo utilizadas.<br />
<br />Esta nueva llamada al sistema, mlock2(), trata de conseguir una solución intermedia. Las páginas de la memoria no son bloqueadas en memoria inmediatamente, sino que se van bloqueando aquellas que van siendo mapeadas en memoria.<br />
<br />
Estas son las novedades principales de este kernel. Como siempre, pueden encontrar la lista completa, y en inglés, en <a href="http://kernelnewbies.org/Linux_4.4">esta página</a>.
Diegohttp://www.blogger.com/profile/18081775339476161685noreply@blogger.com6tag:blogger.com,1999:blog-7974522.post-70608173961744696292015-05-02T22:25:00.002+02:002015-05-02T22:26:36.377+02:00 Las novedades de Linux 4.0Ya se <a href="https://lkml.org/lkml/2015/4/12/178">ha anunciado</a> la versión 4.0 de Linux. Esta versión añade soporte para parchear el kernel en vivo, con el objetivo principal de corregir fallos de seguridad sin reiniciar; también se añade DAX, un sistema para evitar utilizar el cache del kernel cuando los sistemas de archivo funcionan en sistemas con almacenamiento de memoria persistente; kasan, un detector de errores de memoria de use-after-free y out-of-bounds; lazytime, una alternativa a relatime, que provoca que las modificaciones a los metadatos de archivos como atime se hagan sólo en cache y se escriban al disco de modo oportunista para mejorar el rendimiento; overlayfs añade soporte para tener múltiples capas inferiores; se añade soporte de Parallel NFS; y dm-crypt tiene importantes mejoras de escalabilidad. También se han incluido drivers nuevos y muchas otras mejoras y pequeños cambios. La lista completa de cambios, en inglés, puede <a href="http://kernelnewbies.org/Linux_4.0">encontrarse aquí</a>, como siempre.<br />
<br />
<br />
<b>· Cambio de versión completamente abitrario</b><br />
<br />
Esta versión incrementa la versión a 4.0. Esta cambio de 3.x a 4.0 no tiene ningún significado particular y no debe ser asociado con ningún cambio técnico de relevancia en el kernel. Esta versión podía haber sido la 3.20, pero Linus Torvalds se cansó del numero 3, hizo <a href="https://plus.google.com/+LinusTorvalds/posts/jmtzzLiiejc">una encuesta</a>, y lo cambio. Si, es frívolo. Cuanto menos piense sobre ello, mejor.<b> </b><br />
<br />
<br />
<b>· Parcheado en vivo</b><br />
<br />
Esta versión incluye "livepatch", una caraterística que permite parchear el código del kernel en tiempo de ejecución, y que está orientada fundamentalmente a aquellas personas que quieran tener actualizaciones de seguridad sin necesidad de reiniciar. Esta característica nació como resultado de la fusión de kgraft y kpatch, dos intentos de SuSE y Red Hat que fueron iniciados para reemplazar el ahora propietario ksplice. Es relativamente simple y minimalista, y hace uso extensivo de infraestructura ya existente en el kernel (ftrace). El código está contenido en su propio directorio y no necesita "enganches" en el resto de subsystemas.<br />
<br />
En esta versión livepatch no está completo, pero ya proporciona soporte para parchear funciones, incluye una API para los módulos del kernel que contengan los parches, y una API/ABI para espacio de usuario que permite operar los parches (ver cuáles están activos, activarlos, desactivarlos, etc). La mayoría de los CVEs pueden aplicarse de este modo. En esta versión sólo se soporta la arquitectura x86, otras llegarán en futuras versiones.<br />
<br />
<br />
<b>· DAX, acceso directo para sistemas con almacenamiento de memoria persistente</b><br />
<br />
Antes de que sean leídos por los programas, los archivos se copian primero a los caches del kernel, que se encuentran en la memoria RAM. Pero es posible que en los próximos años se popularicen los sistemas basados en la llamada "memoria persistente", que proporcionan enormes cantidades de almacenamiento con velocidades de acceso equivalentes a la memoria RAM y mantendrían los contenidos a pesar de cortes de energía. En estos sistemas, no habría una separación RAM-disco, sino que la memoria persistente es al mismo tiempo memoria RAM y espacio de almacenamiento. En una arquitectura así, los caches del kernel son redundantes.<br />
<br />
Linux ha tenido cierto soporte para este tipo de sistemas <a href="http://kernelnewbies.org/Linux_2_6_13">desde 2.6.13</a>. Pero el código no estaba siendo mantenido y sólo soportaba ext2. En esta versión, Linux añade una nueva implementación llamada DAX. DAX elimina la copia extra de los caches haciendo que las lecturas y escrituras se hagan directamente almacenamiento de memoria persistente. En esta versión se añade soporte para ext4.<br />
<br />
<br />
<b>· kasan, detector de errores de gestión de memoria en el código</b><br />
<br />
Kernel Address sanitizer (KASan) es un detector de errores que detecta bugs use-after-free y out-of-bounds bugs. Linux ya tiene kmemcheck, pero a diferencia de kmemcheck, KASan utiliza instrumentación en tiempo de compilado, lo cual lo hace significativamente más rápido que kmemcheck.<br />
<br />
La idea principal de KASan es almacenar información sobre la seguridad de acceder cada byte de memoria o no, y usar la instrumentación del compilador para comprobar esa información en cada acceso de memoria. KASan utiliza 1/8 de la memoria direccionable por el kernel para mantener esta información.<b> </b><br />
<br />
<br />
<b>· lazytime para una actualización de los tiempos de un archivo más eficiente</b><br />
<br />
Los sistemas Unix mantienen información variada sobre los archivos, tal y como la última vez que un archivo fue accedido o modificado. Mantener esta información es costoso, especialmente la información sobre cuándo fue accedido un archivo por última vez ("atime"), que animó a mucha gente durante mucho tiempo a desactivar la actualización de ese campo con la opción "noatime". Para aliviar este problema se añadió la opción "relatime", que sólo modificaba el campo atime si el archivo había sido modificado hace más de 24 horas. Este comportamiento, sin embargo, provoca errores en ciertos programas que requieren una actualización precisa de atime, y además va en contra del estándar POSIX.<br />
<br />
En esta versión, Linux añade otra alternativa, "lazytime". Lazytime hace que los tiempos de acceso, modificación y cambio se hagan sólo al cache. Los tiempos serán sólo escritos al disco si el inodo es actualizado por otra razón, o si se utilizan llamadas al sistema como fsync(), syncfs() o sync(), o antes de que el caché del inodo vaya a eliminarse de la memoria. Esta manera de funcionar está de acuerdo con POSIX, hace funcionar a los programas que rompía "relatime", y, además, mejora el rendimiento.<br />
<br />
<br />
<b>· Múltiples capas inferiores en overlayfs</b><br />
<br />
En overlayfs, ahora es posible especificar múltiples capas inferiores. Para hacerlo, se puede utilizar los dos puntos (":") como separador entre los diferentes directorios. Por ejemplo:<br />
<br />
mount -t overlay overlay -olowerdir=/lower1:/lower2:/lower3 /merged <br />
<br />
Los directorios inferiores especificados se apilarán uno encima del otro desde el de la derecha al de la izquierda. En el ejemplo anterior lower1 estará arriba del todo, lower2 en el medio y lower3 abajo. "upperdir" y "workdir" pueden omitirse, aunque en ese caso el overlay será de sólo lectura.<br />
<br />
<br />
<b>· Soporte de servidor de Parallel NFS, NFS v4.2 por defecto</b><br />
<br />
Parallel NFS (pNFS) es parte del estándar NFS v4.1 que permite a los clientes acceder a dispositivos de almacenamiento directamente y en paralelo. La arquitectura pNFS elimina los problemas de escalabilidad y rendimiento asociados con los servidores NFS hoy. Esto se logra mediante la separación de datos y metadatos, y moviento los servidores de metadatos fuera de la ruta principal de acceso a los datos.<br />
<br />
Esta versión añade soporte para tener un servidor pNFS en Linux, y se proporcionan drivers para el layout "block", junto con el soporte para utilizar ese layout en sistemas de archivo XFS. También se añade el layout "flexfiles".<br />
<br />
Además, en esta versión la versión por defecto del servidor NFS será NFS v4.2. <br />
<a href="http://git.kernel.org/linus/c23ae6017835b5bc9b9ec9d5d9c2b1523053f503"></a><br />
<br />
<b>· Mejoras de escalabilidad de dm-crypt</b><br />
<br />
Esta versión incrementa significativamente el rendimiento y escalabilidad de CPU de dm-crypt, gracias a unos cambios que permiten un uso más efectivo de todas las CPUs. Los resultados de una serie de tests y benchmarks pueden encontrarse <a href="https://www.redhat.com/archives/dm-devel/2015-February/msg00106.html">aquí</a>.<br />
<br />
Y eso es todo. La lista completa de cambios en inglés, <a href="http://kernelnewbies.org/Linux_4.0">aquí</a>.
Diegohttp://www.blogger.com/profile/18081775339476161685noreply@blogger.com4tag:blogger.com,1999:blog-7974522.post-17486315196911470182015-03-21T22:01:00.003+01:002015-03-21T22:01:32.731+01:00La revolución de DockerEl otro día <a href="http://diegocg.blogspot.com.es/2015/02/snappy-ubuntu-core-una-manera-diferente.html">hablaba de Snappy</a>, el nuevo sistema de paquetes de Ubuntu. La verdad es que este nuevo sistema forma parte de toda una sorprendente ola-moda de virtualización a nivel de sistema de operativo, generalmente de mano de Docker, un software que en muy poco tiempo se ha hecho omnipresente en todas las fiestas. ¿Por qué demonios de repente la virtualización a nivel de sistema operativo de mano de Docker está tan de moda?<br />
<br />
En principio, la virtualización a nivel de sistema operativo no es demasiado nueva. Durante muchos años, se ha oído a FreeBSD presumir de sus <i>jails</i>, y a OpenSolaris de sus <i>zones</i>. En el caso de FreeBSD, sus <i>jaulas</i> existen desde al menos FreeBSD 4.0, publicado en el año 2000, y durante muchos años, esa característica ha sido una de las razones por las que la gente usaba FreeBSD. Linux carecía de soporte de algo equivalente, y aunque existían parches extraoficiales de Linux-VServer desde 2001, sólo atraía la atención de casos particulares: La gente no huía masivamente de Linux por no tener estas capacidades integradas.<br />
<br />
Con el tiempo -más de una década- el Linux oficial ha ido añadiendo <a href="http://en.wikipedia.org/wiki/Cgroups#NAMESPACE-ISOLATION">diversos espacios de nombres</a>, que son las columnas que permiten implementar este tipo de virtualización. Pero incluso cuando se implementó, tampoco parece que se le diera más importancia de la que se daba anteriormente a VServer y OpenVZ. Hasta que llegó Docker.<br />
<br />
Docker. Docker por un lado, Docker por otro, Docker para todo y en todos sitios. Si leen sitios de noticias sobre software libre o programación ya se habrán acostumbrado a (y quizás cansado de) leer noticias relacionadas con Docker. Y es que Docker se ha extendido a gran velocidad. Su código fuente fue publicado en Marzo de 2013. Dos años después, ya es una plataforma soportada en Amazon EC2, Google Cloud y Microsoft Azure. La compañía líder en Linux, Red Hat, anunció un proyecto específico para Docker ya en Abril de 2014, "Atomic Host", y la primera versión estable <a href="http://www.zdnet.com/article/red-hat-buys-into-docker-containers-with-atomic-host/">se publicó</a> a principios de este mes. Y nada menos que Microsoft ya ha anunciado que <a href="https://msopentech.com/blog/2014/10/15/docker-containers-coming-microsoft-linux-server-near/">va a añadir</a> soporte de Docker en la próxima versión de Windows Server. <a href="http://blogs.vmware.com/cto/vmware-docker-better-together/">También VMware</a>, que en principio podría parecer un rival, se apunta a Docker.<br />
<br />
A un software que tenga la capacidad de alcanzar semejante estatus en tan sólo dos años no hay más remedio que describirlo como revolucionario. Y si en dos años ha tenido el efecto que ha tenido, cabe esperar que en los próximos años la expansión de Docker tenga muchas ramificaciones. Pero eso no responde a la pregunta de ¿por qué de repente hay tanta moda de virtualización de sistema operativo?<br />
<br />
En realidad, no creo que haya un gran interés en esta clase de virtualización. Lo que hace a Docker interesante no es tanto su gestión de contenedores, habilidad en la que Docker no es superior a otras herramientas, sino su capacidad para facilitar la gestión de la implementación de "aplicaciones". El <a href="https://registry.hub.docker.com/">registro público de imágenes</a> es una App Store más. No importa tanto el tipo de virtualización sobre el que se ejecuta una imagen (tal y como prueba el hecho de que Microsoft y VMware quieran portar Docker a sus plataformas), lo que importa es poder acceder a la App Store de turno. Del mismo modo que lo que hace relevante a un teléfono hoy es acceder a las tienda de aplicaciones de Android o iOS, existe la posibilidad de que estemos avanzando hacia una situación en la que un sistema que no tenga acceso a la "tienda de aplicaciones Docker", si bien estaría muy lejos de ser un sistema inutil, quedaría marginado por no poder acceder a las aplicaciones de moda.<br />
<br />
La revolución de Docker no sería por tanto "la revolución de Docker", sino un capítulo más de la revolución de las tiendas de aplicaciones.<br />
<br />
Por otro lado, esto no haría más que reafirmar la tendencia de cambio hacia un modelo en el que los repositorios Linux tradicionales quedan obsoletos como sistema para distribuir aplicaciones, y por tanto ponen en duda la esencia de muchas grandes distribuciones Linux. Ubuntu, con su Snappy, es de las primeras grandes distribuciones en prestar atención a este fenómeno, pero está por ver que otras hagan lo mismo. Será interesante observar lo que pase en los próximos años.Diegohttp://www.blogger.com/profile/18081775339476161685noreply@blogger.com3tag:blogger.com,1999:blog-7974522.post-29540399373990505552015-02-24T16:11:00.000+01:002015-02-24T16:11:00.603+01:00KDE Frameworks 5: un ejemploHace 9 días escribí <a href="http://diegocg.blogspot.com.es/2015/02/los-frutos-de-la-modularidad-en-kde-5.html">un post</a> sobre KDE Frameworks 5, hoy encontré <a href="http://www.kdab.com/copying-files-network-qt-application/">este buen ejemplo</a> de cómo una aplicación Qt puede aprovechar una librería de KDE Frameworks (KIO) con facilidad.Diegohttp://www.blogger.com/profile/18081775339476161685noreply@blogger.com2tag:blogger.com,1999:blog-7974522.post-62618524391662966982015-02-22T20:58:00.003+01:002015-02-22T21:08:29.470+01:00Snappy Ubuntu Core, una manera diferente de gestionar paquetesUbuntu <a href="https://insights.ubuntu.com/2014/12/09/a-new-transactionally-updated-snappy-ubuntu-core/">anunció</a> hace un tiempo otra versión de Ubuntu: <a href="http://www.ubuntu.com/snappy">Snappy Ubuntu Core</a>, una especie de equivalente al sistema base de Debian que presenta un nuevo sistema de gestión de software. Su objetivo inicial era presentarlo como plataforma para la nube, más concretamente como plataforma para usar el célebre Docker y así reaccionar frente a CoreOS, que se ha puesto de moda como distro favorita para usar Docker.<br />
<br />
Hace alrededor de un mes, Canonical <a href="https://insights.ubuntu.com/2015/01/20/ubuntu-core-on-internet-things/">anunció</a> que también promocionarían Snappy Ubuntu Core para la "internet de las cosas" (horripilante expresión que, como ya habrán notado, está de moda), es decir, para sistemas del estilo de Raspberry Pi. La reducción del tamaño, consumo energético y coste de estos sistemas hacen posible empotrar estos sistemas en casi cualquier cosa, y como la flexibilidad de un sistema operativo complejo es infinitamente mayor que el firmware de los circuitos integrados, se prevé que en pocos años empecemos a encontrar estos sistemas en todos lados. <br />
<br />
Lo diferente e interesante de Ubuntu Snappy, desde el punto de vista del ecosistema linuxero, es que se deshace por completo del sistema de gestión de paquetes APT. Con toda la literalidad de la expresión. El sistema de gestión de software es el corazón de la identidad de una distro, por lo que estamos ante un cambio importantísimo, y para mi sorpresa muy poco comentado. El cambio es hacia <a href="https://developer.ubuntu.com/en/snappy/">Snappy</a>, un nuevo sistema de gestión de paquetes muy curioso. Snappy es, en concepto, parece ser una imitación y evolución del "updateservicectl" de CoreOS. Técnicamente, es una confluencia de varias tendencias tecnológicas, desde APT al aislamiento de aplicaciones de los teléfonos.<br />
<br />
<br />
<b>Snappy</b> <br />
<br />
Al igual que APT, Snappy (invocado mediante el comando "snappy") consta de repositorios de software. A diferencia de APT, los paquetes no son tal como solemos concebir los paquetes. Existe un paquete llamado "ubuntu-core" que contiene, literalmente, todo el sistema de Snappy Ubuntu Core. Todo. Nada de cientos de paquetes separados, sólo uno para todo el sistema base (es decir, la dirección opuesta a la fisión en infinidad de paquetes que vemos en Debian). Tras el sistema base, existen los "frameworks". Uno de los frameworks posibles es "docker", y es fácil imaginar a "gtk", "qt" o "kde" como ejemplos de otros frameworks que se añadan en el futuro. La finalidad de los frameworks es extender el sistema base.<br />
<br />
Luego tenemos las aplicaciones. La diferencia fundamental entre frameworks y aplicaciones es que las aplicaciones están aisladas entre si mediante virtualización con contenedores, y tienen restringido el acceso al sistema de archivos, a la red, a listados de procesos que muestren otros procesos. Una de las consecuencias inmediatas de esta organización es que desaparece el concepto de dependencias al que estamos acostumbrados. Nada de cientos, miles de paquetes, cada uno con una librería, cada uno con su versión, cada uno con sub-dependencias. En Snappy Ubuntu Core, el paquete de sistema y los paquetes de framework son sólo un paquete cada uno, y las aplicaciones sólo pueden depender de frameworks. <br />
<br />
La última gran diferencia de este sistema es el carácter transaccional y reversible de las actualizaciones, especialmente las del sistema. Gracias a un <a href="https://developer.ubuntu.com/en/snappy/guides/filesystem-layout/">extraño sistema con dos particiones</a>, copiado de CoreOS, las actualizaciones de paquetes del sistema se hacen a la partición que no se está utilizando en ese momento, y al arrancar se utiliza la partición con el sistema nuevo. Con "snappy rollback" se puede volver a utilizar la versión anterior del sistema. En el caso de las aplicaciones, se instalan varias aplicaciones en /app/nombredelaapp/1.2.3, y hay un enlace simbólico en /app/nombredelaapp/current a la versión que se desea utilizar.<br />
<br />
Por último, destacar el enrevesado proceso de ensamblado de las particiones al arrancar. Las particiones que contienen el sistema son de sólo lectura, no se permite su modificación. Eso hace que sea necesario dedicar una partición extra en la que se almacenan las modificaciones o añadidos a /var o /etc. Es también en esa partición donde se instalan las aplicaciones, y donde se crean los directorios de usuario. Naturalmente, esos juegos de particiones no resultan en un sistema funcional por sí solos, de ahí que al arrancar el sistema tenga que hacer un total de 28 montajes <i>bind</i> de la partición modificable a varias rutas en /etc y /var del sistema principal no modificable.<br />
<br />
<br />
<br />
<b>Consecuencias de Snappy</b><br />
<br />
Snappy es muy interesante porque logra mezclar la muy razonable decisión de ejecutar todas las aplicaciones en entornos aislados, con los repositorios tradicionales linuxeros, al mismo tiempo que añade funciones que deberían ser estándar, y no meras opciones, en cualquier sistema de paquetes moderno (revertido de actualizaciones) y elimina aspectos de los repositorios linuxeros (miles de paquetes y laberintos de dependencias) que quizás deberíamos empezar a cuestionar.<br />
<br />
El dilema que puede surgir frente a snappy es que Snappy puede considerarse como algo bueno. Y no sólo bueno: podría incluso considerarse una evolución de los sistemas de paquetes en Linux, algo superior. Y si Snappy es superior, y logra ser mejor que los sistemas de paquetes tradicionales, la evolución lógica sería que Canonical llegase a sustituir en un futuro (futuro no inmediato) a APT por Snappy, con consecuencias impredecibles. Es difícil prever qué pasará exactamente en el futuro (porque hay varios proyectos compitiendo por hacer lo mismo, como Gnome Apps), pero existe la posibilidad de que haya verdaderas revoluciones en las herramientas de gestión de software en el mundo Linux en los próximos años. Snappy bien puede ser sólo el comienzo de una nueva ola.Diegohttp://www.blogger.com/profile/18081775339476161685noreply@blogger.com5tag:blogger.com,1999:blog-7974522.post-56691152791573856532015-02-15T21:14:00.000+01:002015-02-15T21:14:05.566+01:00Los frutos de la modularidad en KDE 5El desarrollo de KDE 5 está siendo bastante caótico de cara al público, mucha gente no sabe bien que se está haciendo. Por eso el anuncio de hoy, publicando <a href="https://www.kde.org/announcements/kde-frameworks-5.7.0.php">KDE Frameworks 5.7.0</a>, no dirá mucho a la gente, ni sabrán si esa publicación acerca, o no, a la publicación de un "KDE 5.0". No les culpo, KDE no ha sabido explicar bien sus intenciones, y yo no tengo intención de hacerlo hoy. Pero merece la pena hablar de KDE Frameworks 5, y de los buenos resultados que está teniendo.<br />
<br />
La intención de KDE Frameworks 5 es hacer honor a su nombre en el sentido más amplio de la palabra: uno de los principales objetivos ha sido que los usuarios de Qt puedan usar partes de las librerías básicas de KDE, sin tener que usar KDE. Para ello, KDE Frameworks 5 ha dividido la gran masa de código "kdelibs" en <a href="http://api.kde.org/frameworks-api/frameworks5-apidocs/">60 pequeñas librerías</a> que ofrecen diferentes funcionalidades, desde KArchive para gestionar archivos comprimidos, KI18n para la internacionalización, KConfig para la gestión de archivos de configuración, o Kemoticons para mostrar emoticonos en lugar de ";)".<br />
<br />
Las dependencias que estas librerías tienen entre sí mismas se distinguen con diferentes "tier". Las que no dependen sólo de Qt forman el "Tier 1", el "Tier 2" lo forman las librerías que dependen del "Tier 1", y el "Tier 3" las librerías con dependencias de las anteriores dos. Las dependencias de librerías y funcionalidades externas, no relacionadas con KDE Frameworks, se gestionan dividiendo las librerías en las que no requieren dependencias ("funcional"), las que requieren alguna para la integración en el sistema ("integration"), o las que tienen otras dependencias variadas ("solution").<br />
<br />
La consecuencia de esta modularización masiva es que KDE Frameworks pasa a ser, en buena medida, una extensión de funcionalidad para Qt, un verdadero framework que pasa a ser desarrollado independientemente de Plasma y las aplicaciones finales de KDE, y que permite crear aplicaciones Qt que utilicen librerías de KDE Frameworks sin tener que forzar a los usuarios a instalar medio KDE.<br />
<br />
Como KDE Frameworks pasa a ser un proyecto complementario de Qt, no debería sorprender que algunas de las librerías de KDE Frameworks hayan sido movidas a Qt: QMimeType proviene de KMimeType, QTemporaryDir de KTempDir, QStandardPaths de KStandardDirs. También se han mejorado otras clases ya existentes, y cuando es posible y recomendable los programadores de KDE intentan mejorar cosas de QT, en lugar de reimplementar cosas por su cuenta.<br />
<br />
El broche final como ejemplo de los beneficios de toda esta modularización se puede comprobar con la <a href="http://sourceforge.net/p/lxde/mailman/message/33373317/">publicación de LXQt 0.9</a>, un escritorio ligero basado en Qt, fusión de LXDE y razor-qt. En esa versión anunciaron que empezarían a usar un componente de KDE Frameworks, <a href="http://api.kde.org/frameworks-api/frameworks5-apidocs/kwindowsystem/html/index.html">KWindowSystem,</a> para gestionar la interacción con el sistema de ventanas. Reutilizarán un código mejor probado y mantenido por otros, y no sólo se libran de tener la implementación de la misma funcionalidad que hacían por su cuenta, sino que todos los esfuerzos que están haciendo en KDE para que KWindowSystem funcione con Wayland redundarán en su beneficio.<br />
<br />
Resumiendo, la modularización de KDE Frameworks 5 supone un gran paso para KDE y el ecosistema Qt. Y aunque no haya un "KDE 5.0", se puede comprobar que el proyecto sigue trabajando mucho y muy bien.Diegohttp://www.blogger.com/profile/18081775339476161685noreply@blogger.com2tag:blogger.com,1999:blog-7974522.post-14006599980006411122015-02-12T19:33:00.002+01:002015-02-12T20:54:34.009+01:00 Las novedades de Linux 3.19Ya se <a href="https://lkml.org/lkml/2015/2/8/199">ha anunciado</a> la versión 3.19 de Linux. Esta versión añade soporte en Btrfs para sustitución rápida de dispositivos y scrubbing en RAID 5 y 6, soporte para las extensiones de protección de memoria de Intel, que ayudan a parar la explotación de desbordamientos de búfer, soporte para la arquitectura AMD HSA, soporte para el sistema de depuración ARM Coresight, soporte para la arquitectura Altera Nios II, soporte para la descarga de las funciones de switchs y routers en chips de hardware, soporte para la preasignación y el borrado de partes de archivos, y el sistema IPC de Android, binder, sale de "staging" y se considera estable. También se han incluido drivers nuevos y muchas otras mejoras y pequeños cambios. La lista completa de cambios, en inglés, puede <a href="http://kernelnewbies.org/Linux_3.19">encontrarse aquí</a>, como siempre.<br />
<br />
<b>· Btrfs: Soporte de scrubbing y sustitución rápida de dispositivos con RAID5&6</b><br />
<br />
Btrfs<b> </b>añadió soporte para la sustitución rápida de discos en Linux 3.8, un método para reemplazar un disco por otro más rápido, en un sólo comando (ver <a href="https://btrfs.wiki.kernel.org/index.php/Manpage/btrfs-replace">btrfs-replace(8)</a>), que hacerlo añadiendo y eliminando manualmente los discos por separado (ver <a href="https://btrfs.wiki.kernel.org/index.php/Manpage/btrfs-device">btrfs-device(8)</a>). Esta característica no podía utilizarse en sistemas de archivos que estuviesen utilizando RAID 5 ó 6. En esta versión se ha eliminado esa limitación.<br />
<br />
<br />
El proceso de hacer scrubbing a un sistema de archivos Btrfs (ver <a href="https://btrfs.wiki.kernel.org/index.php/Manpage/btrfs-scrub">btrfs-scrub(8)</a>) tampoco era posible en sistemas de archivo que usasen RAID 5 ó 6; esta limitación también se ha eliminado.<br />
<br />
<b>· Soporte para las extensiones de Protección de Memoria de Intel</b> <br />
<br />
Las extensiones MPX de Intel (<a href="http://en.wikipedia.org/wiki/Intel_MPX">Memory Protection Extension</a>) son un conjunto de instrucciones de CPU que ayudan a proporcionar fiabilidad al software evitando que las referencias de punteros puedan ser usurpadas maliciosamente por desbordamientos de búfer. Intel MPX introduce nuevos registros y nuevas instrucciones que operan en esos registros. Con compiladores, librerías y kernels modificados, es posible hacer uso de esas instrucciones para que el hardware MPX prevenga la explotación de desbordamientos de búfer. Esta versión de Linux añade soporte para Intel MPX en el kernel. Nota: las CPUs con soporte de MPX aun no están en el mercado y serán introducidas en las microarquitecturas Intel Skylake y Goldmont. <br />
<br />
Artículo LWN recomendado: <a href="http://lwn.net/Articles/582712/">Supporting Intel MPX in Linux</a>.<br />
Artículo de Intel recomendado: <a href="https://software.intel.com/en-us/articles/introduction-to-intel-memory-protection-extensions">Introduction to Intel Memory Protection Extensions</a><br />
<br />
<br />
<b>· Controlador HSA para GPUs AMD</b><br />
<br />
HSA ("Heterogeneous System Architecture") es una arquitectura que integra CPUs y GPUs en el mismo bus. HSA permite que varios tipos de procesador (CPUs, DSPs, GPUs, etc) compartan recursos del sistema con mayor efectividad mediante características del hardware como memoria compartida y paginable, colas de trabajos accesibles desde espacio de usuario, etc.<br />
<br />
Esta versión incluye soporte de HSA para la familia de procesadores Radeon, y ofrece una API que es utiliza por <a href="https://github.com/HSAFoundation/HSA-Runtime-Reference-Source">una librería de software libre</a> desarrollada por AMD, Para más detalles sobre HSA y sobre las posibilidades que HSA ofrece a las aplicaciones de espacio de usuario, ver el anterior enlace.<br />
<br />
<b>· Android binder movido a "stable"</b><br />
<br />
El código del "binder" de Android (un IPC específico para Android) ha estado durante años en el área "staging" del kernel, destinado a código que aun no está preparado para ser utilizado por el público. El código en cuestión, sin embargo, es estable ha sido distribuido en todos los millones de teléfonos Android que se han vendido en todos estos años. Hay reticencias sobre binder, pero no importa lo que pase, Linux va a tener que soportar esta API de todos modos, lo cual ha motivado que pase a estar considerado como código estable.<br />
<br />
<b>· Soporte de ARM Coresight</b><br />
<br />
Coresight es un paraguas de tecnologías que permiten la depuración en SoCs ARM. ARM ha desarrollado una solución de trazado de software asistido por hardware, compuesta de diferentes partes, cada una de las cuales está destinada a una necesidad de trazado específica.<br />
<br />
El framework Coresight de Linux proporciona una interfaz para los drivers que soportan las diferentes partes de Coresight. Ofrece una vista topológica de los componentes de Coresight y configura los diferentes componentes cuando se activa una fuente de trazado. Para más detalles sobre el framework ver <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/trace/coresight.txt">Documentation/trace/coresight.txt</a> , para más detalles sobre ARM Coresight ver <a href="http://www.arm.com/products/system-ip/debug-trace/">http://www.arm.com/products/system-ip/debug-trace/</a> <br />
<br />
<b>· Nueva arquitectura: Procesadores Altera Nios II</b><br />
<br />
Esta versión añade soporte para los procesadores Altera Nios II. Nios II es una arquitectura de procesadores embebidos de 32 bits, diseñados específicamente para la familia de FPGAs Altera. El procesador Nios II ofrece varias mejoras sobre la arquitectura original Nios, haciéndolo ideal para un amplio rango de aplicaciones embebidas, desde DSPs a sistemas de control. Para más información sobre los procesadores Nios II, ver <a href="http://www.altera.com/literature/lit-nio2.jsp">http://www.altera.com/literature/lit-nio2.jsp</a> <br />
<br />
<b>· Device Tree Overlays</b><br />
<br />
El "Device Tree" es una estructura de datos para describir el hardware, esta estructura de datos se pasa al kernel al arrancar, una solución más flexible que tener que incluir cada detalle de los dispositivos en el sistema operativo. Se usa sobre todo en arquitecturas como PowerPC y ARM. El Device Tree está diseñado para sistemas estáticos, y tiene problemas para extenderse a buses de expansión como los que se encuentran en sistemas de consumo como el BeagleBone o Raspberry Pi.<br />
<br />
Esta versión introduce soporte para overlays ("superposiciones") en el Device Tree. Los overlays son un método para modificar dinámicamente partes del Device Tree y hacer cambios. Esto hace más sencillo soportar sistemas como los anteriormente citados. Para más información, leer: <a href="http://lwn.net/Articles/616859/">Device tree overlays</a>.<br />
<br />
<b>· Redes: Soporte para descargar el procesado de routers y switchs</b><br />
<br />
Esta versión incluye una infraestructura para soportar chips de switchs y otras operaciones de red. De ese modo, el procesado de esas funciones puede hacerse en el hardware, y así evitar tener que hacerlo en software.<br />
<br />
También se incluye el primer driver que utiliza esta infraestructura, un driver "rocker" para el chip de switch <a href="https://github.com/sfeldma/qemu-rocker/">emulado en qemu</a>. <br />
<br />
<b>· Soporte de preasignación y "hole punching" en NFSv4.2</b><br />
<br />
Esta versión añade soporte para la preasignación de archivos y "hole punching" (eliminación de porciones grandes de un archivo) en NFSv4.2<br />
<br />
<br />
Y eso es todo. La lista completa de cambios en inglés, <a href="http://kernelnewbies.org/Linux_3.19">aquí</a>.Diegohttp://www.blogger.com/profile/18081775339476161685noreply@blogger.com4tag:blogger.com,1999:blog-7974522.post-21097875394836660102014-12-18T21:06:00.001+01:002014-12-18T21:06:24.961+01:00 Las novedades de Linux 3.18Ya se <a href="https://lkml.org/lkml/2014/12/7/202">ha anunciado</a> la
versión 3.18 de Linux. Esta versión añade soporte para overlayfs, que permite combinar dos sistemas de archivos en un sólo punto de montaje, se añade soporte para mapear memoria de espacio de usuario en la memoria de vídeo en los drivers Radeon, se añade una llamada de sistema bpf() que permite la ejecución de programas en bytecode al estilo de BPF; se añade también un algoritmo de congestión de tráfico TCP optimizado para centros de datos, un protocolo de encapsulado optimizado para virtualización, soporte para incrustar protocolos IP en paquetes UDP, y soporte de la capa de bloques multi-cola en la implementación SCSI. También se han
incluido drivers nuevos y muchas otras mejoras y pequeños cambios.
La lista completa de cambios, en inglés, puede <a href="http://kernelnewbies.org/Linux_3.18">encontrarse aquí</a>, como siempre.<br />
<br />
<br />
<b>· Overlayfs</b><br />
El sistema de archivos<b> </b>overlayfs permite combinar dos sistemas de archivos, uno "superior" y otro "inferior", en un sólo punto de montaje. Las modificaciones a ese sistema de archivos mezclado se hacen en el sistema de archivos superior. Este sistema tiene muchos usos, pero es conocido sobre todo por ser utilizado en los live-CD, en los que se monta una imagen del sistema operativo como sistema de archivos inferior, y un sistema de archivos en RAM, en el que se hacen las modificaciones, como superior; de ese modo se puede utilizar el live-CD como un sistema real. Overlayfs se diferencia de otros mecanismos de unión de sistemas de archivos en que tras abrirse un archivo todas las operaciones van a los sistemas de archivos inferiores o superiores, lo cual simplifica la implementación y permite tener rendimiento nativo.<br />
<br />Es posible que ambos arboles de directorio estén en el mismo sistema de archivos. El sistema de archivos inferior puede ser cualquier sistema de archivos soportado por Linux y no necesita permisos de escritura. El sistema de archivos inferior puede ser otro overlayfs. El sistema superior será normalmente escribible y si lo es debe permitir la creación de atributos extendidos trusted.*, y debe retornar un d_type válido en readdir(), de modo que NFS no está permitido.<br />
<br />
<b>· Radeon: mapeado de espacio de usuario en la memoria de vídeo</b><br />
Linux 3.16 añadió la posibilidad de mapear direcciones de espacio de usuario en la memoria de vídeo para chips Intel. En esta versión, también se ha incorporado en el driver Radeon soporte de esta característica, que permite utilizar datos de la aplicación como fuente para
texturas o incluso como destinación de un proceso de renderizado
(dependiendo de las capacidades del chipset). Esto tiene usos útiles,
tales como descargas de memoria a la GPU sin copias y mejoras de
rendimiento en varios casos. Esta capacidad tiene consecuencias
extensas, desde renderizado por software más veloz (chromium) o
mitigación de pausas en ciertos casos en firefox.<br />
<br />
<b>· Llamada al sistema bpf() para programas de máquina virtual eBPF</b><br />
<br />
La llamada al sistema bpf() es un multiplexador para una serie de operaciones en eBPF que pueden ser descritas como "máquina virtual universal en el kernel". eBPF es similar al Berkeley Packet Filter que se usa para filtrar paquetes de red. eBPF "extiende" el BPF clásico de múltiples maneras incluyendo la capacidad de hacer llamadas a funciones de ayuda en el kernel y acceso a estructuras de datos compartidas. Los programas pueden ser escritos en un C restringido que se compila a bytecode eBPF y se ejecuta en la máquina virtual eBPF o se convierte en instrucciones nativas con un JIT.<br />
<br />
Los programas eBPF son similares a módulos de kernel. Los carga un proceso de usuario y se descargan automáticamente cuando el proceso sale. Cada programa eBPF es un conjunto de instrucciones seguro. El verificador eBPF determina estáticamente que el programa termina y es seguro de ejecutar. Los programas pueden estar conectados a diferentes eventos. Estos eventos pueden ser paquetes o eventos de trazado. Más allá de almacenar datos los programas pueden llamar a funciones de ayuda del kernel que podrían, por ejemplo, volcar la pila, invocar trace_printk u otras ayudas para la depuración del kernel.<br />
<br />
<b>· TCP: algoritmo de congestión Data Center TCP</b> <br />
Esta versión añade el algoritmo de control de congestión Data Center TCP (DCTCP). Se trata de un algoritmo diseñado para optimizar el rendimiento de las redes de centros de datos, centrándose en proporcionar: alta resistencia a las ráfagas de tráfico alto, baja latencia y alto rendimiento.<br />
<br />
<b>· Geneve: Protocolo de encapsulación para virtualización </b><br />
El advenimiento de las redes virtualizadas ha provocado un aumento del interés y de la creación de nuevos protocolos. Los protocolos de túneles existentes han intentado resolver diferentes aspectos de los nuevos requerimientos de las redes virtualizadas, pero pronto quedaban desfasados. Linux 3.18 añade Geneve, un protocolo que intenta evitar esos problemas proporcionando un protocolo para túneles que proporciona redes de nivel 2 sobre redes de nivel 3.<br />
<br />
<b>· Mejora del rendimiento de red: agrupación del procesamiento de la cola de envío</b><br />
Esta versión añade soporte para retrasar el procesado de SKBs (buffers de sockets). Procesar la cola de envíos del driver de la tarjeta de red es costoso, de modo que es posible compartir ese coste acumulando varios búfers y procesándolos al mismo tiempo. Varios drivers han incorporado esta característica: i40e, igb, ixgbe, mlx4, virtio_net, se añadirán más en futuras versiones.<br />
<br />
<b>· Soporte para foo-sobre-UDP</b><br />
Esta versión añade soporte para encapsular cualquier protocolo IP sobre UDP incluyendo túneles (IPIP, GRE, SIT).<br />
<br />
La motivación para esta funcionalidad es que el hardware y software de red existente están optimizados para UDP y pueden utilizarse para proporcionar un mejor servicio. En esta versión se ha añadido soporte para usar foo-sobre-UDP en GRE, IPIP, y SIT. Se ha añadido un nuevo comando "ip fou" en las nuevas versiones de ip para usar esta característica.<br />
<br />
<b>· Soporte de SCSI multicola opcional</b><br />
Linux 3.13 añadió un nuevo diseño para la capa de bloques que permitía procesar múltiples colas IOs en paralelo. Esta característica, sin embargo, no era transparente y requería adaptación de los drivers. En esta versión, se ha añadido soporte para esta capa multi-cola en la capa SCSI (usada por los drives ATA y SATA) como una opción<br />
<br />
Y eso es todo. La lista completa de cambios en inglés, <a href="http://kernelnewbies.org/Linux_3.18">aquí</a>.<br />
<br />
Diegohttp://www.blogger.com/profile/18081775339476161685noreply@blogger.com0tag:blogger.com,1999:blog-7974522.post-85866656291221794182014-11-16T21:34:00.000+01:002014-11-16T21:34:16.619+01:00Android 5, una versión para olvidar las anterioresAyer <a href="http://www.fundeu.es/consulta/flas-y-flash-589/">flaseé</a> Android 5.0 a mi Nexus 4 -un modelo que ya tiene dos años-, y he podido comprobar como todas las cosas buenas que se dicen sobre esta nueva versión son ciertas. La interfaz es mejor, el uso ingente de animaciones por doquier no me resulta molesto porque se utilizan para explicar visualmente las transiciones de los elementos de la interfaz, el uso de batería ha mejorado enormemente, y mejorará más a medida que las aplicaciones hagan uso de <a href="https://developer.android.com/about/versions/android-5.0.html#Power">las nuevas APIs</a>, las notificaciones, runtime ART, etc. Me he topado ya con un par de crashes de aplicaciones del sistema, pero nada que se salga de lo habitual en una version .0.<br />
<br />
Lo paradójico de Android 5.0 es que las mejoras son tan buenas, que ponen en evidencia una verdad impopular: Android 4.x era una castaña.<br />
<br />
Seguramente muchos hayan leído alguna vez el mote burlesco "lagdroid", referente a la lentitud y falta de respuesta de la interfaz de Android. ¿Cuántas veces han escuchado a fans de Android decir que en esta nueva subversión, en este nuevo teléfono último modelo, el "lag" pasaba a ser historia? Pues no, el lag seguía ahí. Cierto, la respuesta de la interfaz mejoró mucho en las últimas versiones (especialmente con las <a href="https://www.youtube.com/watch?v=vQZFaec9NpA">mejoras de 4.3</a>). Pero no dejó de existir.<br />
<br />
La notable mejora de rendimiento del nuevo runtime java ART -que estaba en 4.4, pero sólo opcional en el menú para desarrolladores- es la mejor prueba de que hasta ahora, usar Android era usar un sistema lento. El propio Google cita, como característica de ART en 5.0, una interfaz con mejor respuesta. Y en esta versión se incorpora también un proceso dedicado a hacer las animaciones, para que sean siempre fluidas. Y hay que tener en cuenta que el salto de Dalvik a ART sea tan grande no implica necesariamente que ART tenga un rendimiento sobresaliente. Mientras tanto, los usuarios de iPhone y Windows Phone han disfrutado de una interfaz con buena respuesta desde el primer día.<br />
<br />
Lo mismo se puede decir del uso de batería: Las mejoras de 5.0 <a href="http://arstechnica.com/gadgets/2014/07/examining-project-volta-we-put-android-l-through-our-battery-test/">son brutales</a> (en gran parte, por el cambio a ART), y no responden a un paso adelante respecto a otros sistemas, sino a una puesta al día de Android.<br />
<br />
Digo todo esto porque existe un intenso fenómeno de fandroidismo en Internet y un desprecio hacia Apple y a sus productos, que se venden a precio de oro a pesar de ser menos versátiles y menos capaces; y también hacia Windows Phone. Está muy bien usar Android -yo también lo uso-, pero el elitismo fandroidero sobra. Vistos los defectos de anteriores versiones de Android, comprar un iPhone o Windows Phone estaba plenamente justificado, y probablemente lo siga estando en muchas facetas. Aunque gracias a Android 5, eso si, en muchas menos.Diegohttp://www.blogger.com/profile/18081775339476161685noreply@blogger.com14