LinuxParty

Si eres lector de LinuxParty, te acordarás que ya habíamos hablado del esperado núcleo de Linux, todos esperábamos por la versión 2.6.38... que... ¿por qué esperábamos tanto al kernel 2.6.38?, pues mira, lee estos dos artículos:

  Un parche de 200 líneas, hace que Linux haga Maravillas.

Luego, dijo alguien que esas mejoras se podían hacer de forma inmediata sin esperar a la versión del Kernel...

  Alternativa al parche de las 200 líneas del código de Linux.

De todas formas, las mejoras que se incorporen a la versión 2.6.38 y superiores no requerirán la modificación de ningún fichero de forma manual, y si algunas de las líneas de los scripts se modifica de forma arbitraría (si ya habías realizado la modificación alternativa), seguirá funcionando sin problemas, ya que la mejora está en el núcleo.
El núcleo, que te lo puedes descargar desde:

• http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.38.tar.bz2
• http://www.kernel.org/pub/linux/kernel/v2.6/patch-2.6.38.bz2

 Tiene las siguientes novedades (Extraido del blog de Diego D'Oh!):

Ya se ha anunciado la publicación de la versión 2.6.38 de Linux. Las novedades de esta versión son:

• Agrupación automática de procesos (el "parche que hace milagros")
• Mejoras de escalabilidad en el VFS
• Compresión LZO y snapshots de sólo lectura en Btrfs
• El protocolo de redes Mesh B.A.T.M.A.N. (que ayuda a proveer de conectividad de red en presencia de desastres naturales, conflictos militares o censura de Internet)
• Soporte gráfico para AMD Fusion, páginas grandes transparentes en lugar de a través de hugetblfs, y muchos otros cambios menores y drivers nuevos. Lista completa en inglés en este enlace.

· Agrupación automática de procesos: La característica más impactante de esta versión es el "parche que hace milagros", que es un parche que hace cambios sustanciales al modo en que se asigna tiempo de CPU a cada proceso. Con esta característica el sistema agrupará todos los procesos que tengan el mismo ID de sesión como una sola entidad. Ejemplo: Imaginemos 6 procesos que están consumiendo CPU continuamente, los 4 primeros con un mismo ID de sesión y los otros dos utilizando otras dos sesiones diferentes.

Sin agrupación automática: [proc. 1 | proc. 2 | proc. 3 | proc. 4 | proc. 5 | proc. 6] 
Con agrupación automática: [proc. 1, 2, 3, 4  |     proc. 5       |     proc. 6      ]

El ID de sesión es una propiedad de los procesos en los sistemas Unix (poco conocida - puede verse con comandos como ps -eo session,pid,cmd). Los hijos lo heredan del padre tras fork(), y pueden empezar una nueva sesión utilizando setsid(3). Bash crea una sesión nueva cada vez que se inicia, lo cual significa que con esta característica se puede ejecutar "make -j20" dentro de una shell en un escritorio, sin que se note mientras se navega la web. Esta característica está implementada sobre la característica "group scheduling" (incluida en 2.6.24). Se puede desactivar en /proc/sys/kernel/sched_autogroup_enabled

· Escalabilidad del VFS: escalando el caché de directorios: Existen actualmente esfuerzos para hacer que la capa VFS ("Virtual File System", el código que va entre las llamadas al sistema y el sistema de archivo) sea más escalable. En versiones anteriores ya se incluyeron algunos cambios preliminares, en esta versión tanto el dcache ("caché de directorios") y el mecanismo entero de búsqueda de rutas se ha reescrito para ser más escalable (detalles en este artículo de LWN).

Estos cambios hacen al VFS más escalable en cargas multihilo , pero lo más interesante (y es lo que le gusta a Linus Torvalds) es que también hacen las cargas con un sólo proceso más rápidas (debido a la eliminación de operaciones de CPU atómicas): En su $HOME, "find . -size" es un 35% más rápido. Ejecutar un "git diff" en un repositorio de kernel cacheado es un 20% más rápido (64 git diff en paralelo en 64 repositorios de kernel son un 26x más rápido). Todo lo que llame a stat(3) con mucha frecuencia es más rápido.

· Compresión LZO y snapshots de sólo lectura en Btrfs: Btrfs añade a su sistema de compresión transparente soporte para el algoritmo de compresión LZO, como alternativa a zlib. Aquí hay una pequeña comparación de rendimiento de ambos.

También se añade soporte para marcar un snapshot como de sólo lectura. Finalmente, los sistemas de archivos Btrfs que encuentren errores serán remontados automática en modo de sólo lectura, lo cual es un paso adelante para hacer al código más resistente errores

· Páginas grandes transparentes: Los procesadores manejan la memoria en pequeñas unidades llamadas páginas (que son de un tamaño de 4 KB en x86). cada proceso tiene un espacio de direcciones de memoria virtual, y hay una "tabla de páginas" donde se guardan todas las correspondencias entre la página del espacio de direcciones de memoria virtual de cada proceso y su página real de RA. El trabajode buscar en la tabla de páginas para encontrar qué página RAM corresponde a cada dirección virtual es muy costoso, así que la CPU tiene un cache de traducciones recientes. Sin embargo, este caché no es muy grande y sólo soporta páginas de 4 KB, asi que muchas cargas (bases de datos, KVM) tienen problemas de rendimiento porque no se pueden cachear todas sus direcciones virtuales.

Para resolver este problema, los procesadores modernos añaden entradas de cache que soportan páginas mayores que 4 KB (como 2 ó 4 MB). Hasta ahora, la única manera que el espacio de usuario tenía de usar esas páginas era con hugetblfs. Esta versión añade soporte para usar esas páginas grandes automáticamente cuando sea posible. Las páginas grandes pueden configurarse para ser usadas siempre o sólo a medida que se pidan mediante madvise(MADV_HUGEPAGE), y su rendimiento puede cambiarse en tiempo de ejecución en /sys/kernel/mm/transparent_hugepage/enabled. Para más detalles, lea Documentation/vm/transhuge.txt

· Tráfico saliente de red se expande automáticamente a varias CPUs con tarjetas de red multiqueue: Esta característica, apodada XPS, implementa un sistema queasigna una CPU a cada queue de la tarjeta de red, con lo cual se reparte la carta entre varios procesadores y se aumenta el rendimiento. Es algo análogo a RPS, que es algo análogo (pero no idéntico) a esto pero para tráfico de entrada. En un benchmark de netperf con 500 instancias de netperf TCP_RR con 1 byte de petición en un sistema AMD con 16 cores:
Con XPS (16 queues, 1 TX queue per CPU) 1234K al 100% CPU
Sin XPS (16 queues) 996K al 100% CP.

· Protocolo B.A.T.M.A.N.: B.A.T.M.A.N. is un alias para "Better Approach To Mobile Adhoc Networking". Una red ad hoc es una red descentralizada que no se basa en infraestructuras previas, como routers o puntos de acceso. En su lugar, cada nodo participa en el enrutado siendo el mismo un router y enviando datos de otros, y de ese modo la determinación de las rutas se hace dinámicamente, basándose en la conectividad que va surgiendo. B.A.T.M.A.N. es una implementación de una de esas redes. B.A.T.M.A.N es útil para situaciones de emergencia como desastres naturales, conflictos militares o censura de Internet. Más información del proyecto en http://www.open-mesh.org/

· Soporte gráfico de AMD Fusion: Pues eso, soporte de las APUs AMD Fusion, que unen GPU y CPU.