[Linux] El parche milagroso de Mike Galbraith en acción

En la página de Phoronix esta mañana leí un artículo sobre un “fascinante parche” para el kernel Linux que permite agregar “grupos de tareas” para una mejor respuesta del kernel ante eventos, haciendo que aplicaciones de escritorio sean agrupadas por TTY aumentando la interactividad del escritorio en alta carga.

La noticia fué replicada por la gente de muyLinux bajo el nombre de “El milagro de las 200 líneas de código” …

El parche …

Este parche fué creado por Mike Galbraith, un eterno colaborador del Kernel Linux (nick: efault) y su finalidad principal es otorgar la posibilidad de “agrupar tareas” en las TTY para que el CPU pueda “procesar en lote” todo ese grupo de tareas de una manera más rápida, aprovechando el procesamiento “en paralelo” *casí* todas las tareas relativas al uso de escritorio (sobre todo en el rendering de video) se ven beneficiadas.

¿Cómo funciona?

Cuando una tarea se ejecuta, esta genera un “GROUP” de manera automática donde todos los childs (hijos) comparten el “task group” y este un único tty. El parche de hecho es una “prueba de concepto” de una idea que Linus Torvalds había propuesto sobre el comportamiento de los task groups y queda abierta a mejoras de todo tipo.

Para ser una prueba de concepto (sólo 200 líneas de código) se desempeña bastante bien.

¿Dónde y cómo implementarlo?

El parche aún se encuentra en pruebas y no ha sido empaquetado en ningún lado, se encuentra como respuesta a un correo de discusión de Linus Torvalds acá, y sólo puede ser implementado en kernels donde la gestión de carga de trabajo de las TTY existe (> 2.6.37), yo he descargado y copiado el parche acá:

http://anyhub.net/file/W_n-rfc-rft-v3-sched-automated-per-tty-task-groups.patch.tar.bz2

De donde lo pueden bajar limpio y sin inconvenientes.

He descargado el kernel 2.6.37-rc2 de la página de kernel.org, lo descomprimo para compilarlo “de la manera habitual”, sin embargo:

Ejecutamos:

make mrproper

Y la copia de las opciones “por defecto”

make oldconfig

Ahora aplicaremos el kernel, para ello lo descomprimimos en la raíz de /usr/src, nos movemos a la carpeta del kernel:

cd linux-2.6.37-rc2/

Y ejecutamos el parche:

patch -p1 --dry-run < ../RFC-RFT-v3-sched-automated-per-tty-task-groups.patch

Opciones habilitadas en el Kernel:

Ejecutando make menuconfig o make gconfig (si están en gnome) activaremos las siguientes opciones del Kernel Linux:

En “General Setup”:

Kernel compression mode:
LZO (el más rápido en descomprimir)

Para que el kernel se descomprima rápidamente pueden activar el modo de compresión LZO, pero requieren instalar el siguiente paquete:

aptitude install lzop
Enable Block Layer > IO Schedulers > CFQ I/O Scheduler > CONFIG_CFQ_GROUP_IOSCHED

Esto habilita el I/O scheduler por grupos (CFQ_GROUP_IOSCHED)

Control Group Support (CONFIG_CGROUPS):
Namespace cgroup subsystemFreezer cgroup subsystemDevice Controller for cgroups
CPUset support > include legacy

Precisamente la opción que incorpora el parche, los CGROUPS y su control.

Resource counters > Memory Resource controller > MRC for Swap Extension
Group CPU Scheduler (CONFIG_CGROUP_SCHED)
Group Scheduling for SCHED_OTHER
Group Scheduling for SCHED_RR/FIFO

Con esto, habilitamos todos los tipos de sheduler basado en grupos.

Block IO Controller
Default I/O scheduler
CFQ

Opciones que colaboran con el parche.

Processor type and features > Preemption Model > Preemptible Kernel (low-latency desktop)

Requerido, para que podamos contar con un kernel Preemtivo. (de baja latencia).

MTRR support > MTRR Cleanup support
Timer Frequency > 1000 Hz

Otras opciones que colaboran con el performance del kernel Linux.

Compilando

Compilamos de la manera usual:

  • make all
  • make modules
  • make modules install
  • make install
  • mkinitramfs -o /boot/initrd.img-2.6.37-rc2-amd64 /lib/modules/2.6.37-rc2-amd64

Y actualizamos nuestro grub para que agregue la entrada del kernel:

update-grub2

y Listo, ahora, a probar el kernel.

Pruebas

Aun cuando hay pruebas más especializadas (como el interbench diseñado por Con Kolivas) yo he hecho una simple prueba (repetible por cualquiera) y que demuestra los beneficios directos del tunning; en este caso, he comprobado con 3 Kernel Linux y diversos modos.

Como nota adicional, mi equipo es:

Linux lexotanil 2.6.37-rc2amd64 #2 SMP PREEMPT Tue Nov 16 16:32:42 VET 2010 x86_64 GNU/Linux

Es un Debian Squeeze, tiene servicios cargados (openldap, postgresql, mysql) y utilidades de escritorio (compiz-fusion, gnome-applets, metacity como gestor, rendering habilitado según guía en este mismo blog) por lo que este parche *podría* en teoría, ser muchisimo más beneficioso para gente con equipos basados en distribuciones Desktop (Ubuntu, Trisquel), que mi equipo que es un servidor, sin embargo, el incremento de rendimiento fue brutal!.

A este equipo se le han realizado los siguientes cambios, con el fin de mejorar su performance:

En la primera prueba, se probó en un Kernel “genérico Debian” sin ninguna modificación al equipo:

Kernel genérico, sin 3D ni MTRR:

glxgears -info
GL_RENDERER   = Software Rasterizer
GL_VERSION    = 2.1 Mesa 7.7.1
GL_VENDOR     = Mesa Project
1494 frames in 5.0 seconds = 298.796 FPS
1582 frames in 5.0 seconds = 316.213 FPS
1616 frames in 5.0 seconds = 323.090 FPS

Los tiempos en promedio, son unos 300 FPS.

Kernel genérico, sin aceleración 3D (pero corrección MTRR activa):

glxgears -info
GL_RENDERER   = Software Rasterizer
GL_VERSION    = 2.1 Mesa 7.7.1
GL_VENDOR     = Mesa Project
2277 frames in 5.0 seconds = 455.288FPS
2314 frames in 5.0 seconds = 462.779 FPS
2251 frames in 5.0 seconds = 450.191 FPS

Mismo kernel, pero con el MTRR corregido (mejora del 10%).

Con aceleración 3D, sin parche de Mike:
glxgears -info
GL_RENDERER   = Mesa DRI Intel(R) 965GM GEM 20091221 2009Q4
GL_VERSION    = 2.1 Mesa 7.7.1
GL_VENDOR     = Tungsten Graphics, Inc
3618 frames in 5.0 seconds = 723.600 FPS
3448 frames in 5.0 seconds = 689.600 FPS
3511 frames in 5.0 seconds = 702.200 FPS

Con 3D y MTRR corregido, el rendimiento en el kernel “genérico” es notable (promedio: 700 FPS).

Kernel con parche realtime (RT Linux): 2.6.33.7-rt29-amd64

GL_RENDERER   = Mesa DRI Intel(R) 965GM GEM 20091221 2009Q4
GL_VERSION    = 2.1 Mesa 7.7.1
GL_VENDOR     = Tungsten Graphics, Inc
3418 frames in 5.0 seconds = 683.600 FPS
3483 frames in 5.0 seconds = 696.600 FPS
3498 frames in 5.0 seconds = 699.460 FPS

Este Kernel (2.6.33-7 con parche RT de RT-Linux) lo uso para transmitir por radioGNU en modo tiempo-real.

Parche de Mike Galbraith; Kernel 2.6.37-rc2-amd64 con parche:

glxgears -info
GL_RENDERER   = Mesa DRI Intel(R) 965GM GEM 20091221 2009Q4
GL_VERSION    = 2.1 Mesa 7.7.1
GL_VENDOR     = Tungsten Graphics, Inc
5707 frames in 5.0 seconds = 1141.172 FPS
6153 frames in 5.0 seconds = 1230.600 FPS
6280 frames in 5.0 seconds = 1255.749 FPS

Como vemos, este parche incrementa en más del 70% la respuesta del Kernel a eventos como dibujado de pantalla, scroll, renderizado de video, etc.

Un screenshot acá:

En el screenshot se ve:

  • Chromium browser: con un video de youtube y otro con el FishIE Tank de HTML5
  • Firefox con unas 15 pestañas abiertas
  • Icedove con mis 3 buzones IMAP abiertos
  • GLXGears
  • Mplayer mostrando otro video
  • Una consola de gnome-terminal con 5 pestañas
  • un editor de texto (mi bitácora)
  • Gnome con Compiz-Fusion activado
  • Varias ventanas de nautilus

Como verán, la respuesta del kernel nunca fué poner el CPU en on-demand (1.6 Ghz) no fué necesario, ya que la carga paralelizada en Debian hizo que el CPU nunca llegara a más del 90% de su carga.

Nota: no hagan caso de la temperatura, vivo en la ciudad de Barquisimeto y hoy fué un día extremadamente caluroso (por encima de 32 grados centígrados). =P

Conclusiones

Hice pruebas y benchmarks también con el interbench de Con Kolivas, que aunque confirman los resultados acá expuestos, sería muy largo explicar el test cuando un glxgears reportaría iguales resultados (una mejora notable en la respuesta del equipo).

Espero hagan sus propias pruebas y permitan dar por sentado que este parche representa el futuro del alto rendimiento en Linux PREEMPT para usuarios comunes y corrientes de escritorio.

Acerca de phenobarbital

http://about.me/phenobarbital

Publicado el 16 noviembre 2010 en Cultura Libre, Linux, PlanetaLinux, Software Libre, Weyu. Añade a favoritos el enlace permanente. 27 comentarios.

  1. Qué bueno que te hayas tomado el tiempo para hacer estas pruebas. También leí la buena noticia esta mañana. Estas 200 líneas combinan MUY bien con el futuro Canaima GNU/Linux 3.0.🙂

  2. Excelente!! Aunque no lo veo en canaima 3.0 (por lo de la inestabilidad del kernel, etc, etc, ), lo implementare en mi Aspire One N150 inmediatamente😀

  3. Aja y una ciudadana con ubuntu 10.10 y con cero manejo de “kerneleses” pero que necesita “enseñarle” a su kernel a que aprenda a manejar varias cosas a la vez de modo ordenado porque siendo potente se recalienta y se ralentiza sin necesidad … cómo le hace para instalar esta maravilla?

    • Pues lo ideal sería tomar el kernel 2.6.37 de ubuntu 10.10 (el de pruebas) y aplicarle este parche para luego “re-empaquetarlo” como .deb.

      Luego que esté como .deb es de instalar de la manera usual🙂

      Veré si con tiempo lo empaqueto! …

  4. Wow, se ve excelente, que chevere que hiciste el benchmark. Deberian agilizar el desarrollo para ver si lo introducen en el kernel 2.6.38

    • Si!, se ve muy prometedor, sobre todo para ser una prueba de concepto, el hilo de discusión está bastante extenso y tiene defensores como el propio Linus Torvalds y Oleg Nesterov de Red Hat, es muy probable que las mejoras sean incorporadas al staging-next esta semana y podamos contar con este parche para el kernel 2.6.38 … esperemos!

  5. Deberian incorporarlo a la version final de la 2.6.37 aunque estuviese en fase “RC”, es una pena que haya que esperar a las versiones de la 2.6.38 para tener este parche funcionando.

  6. Saludos, en que diferencian el kernel que probaste y un kernel real-time. Cual sería más eficiente o de mejor perfomance?. Por cual se debería inclinar el usuario común, pero que desea que sus aplicaciones se ejecuten con mayor rapidez y fluídez.

    Gracias por tus aportes y tus publicaciones.

    • En un kernel realtime, el tiempo de latencia-respuesta del kernel es reducido al mínimo, esto para ciertas aplicaciones como edición de audio o video son ideales, eso no quiere decir que navegarás más rápido o compilarás más rápido o verás los video más fluído, puesto que esto depende del scheduler (forma como se gestionan las tareas en su conjunto) y no de la “latencia” que las aplicaciones tengan contra el kernel, que ciertamente también ayuda …
      Lo que hace el parche es optimizar el uso de recursos de las TTY para que sean mejor administrados y en grupos de tareas, léase que esto no mejorará tu navegador, pero si le permitirá al gnome dibujar ventanas más rápido, podrás hacer cosas “en paralelo” que no son de usuario común como compilar (grupo de tareas) y ver un pelicula con mplayer (otro grupo de tareas), de resto aplicaciones que no gestionan TTY (como openoffice) no se verán afectadas …
      En general, solo el performance 3D (juegos, videos, etc) y el de dibujado de ventanas (gnome) se ven beneficiados con el parche y eso ya es mucho! …

      Esperemos a una combinación de parches (Brain Fuck Scheduler de Con Kolivas, Realtime de Ingo Molnar y Group-tasks de Mike Galbraith) para 2.6.38 para contar con un verdadero y único kernel Linux optimizado para usuarios de escritorio.

  7. Hola, falta una “t”, es mkinitramfs

    Saludos!

  8. Otra cosa, al hacer este ultimo comando me saltaba que no encontraba el archivo modules.dep, se soluciono poniendo “make modules_install” en vez de “make modules install”. No se si es general o solo en mi caso, pero vi que ponen así.

  9. Ya lo tengo instalado con mi Lubuntu en una VAIO-N160G.

    ¡Luce bien!. Hacía rato que no generaba mi propio kernel……:)

  10. Hola, ¿Estás seguro sobre lo que dices de que solo puede ser implementado en Kernels > 2.6.37?

    En el articulo de Phoronix hablan de que lo implementaron en el 2.6.37, pero en el foro se habla mucho de haberlo implementado en la 2.6.36?
    http://www.phoronix.com/forums/showthread.php?t=27138

    Estaría agradecido si me pasas el enlace eso que comentas sobre la versión del kernel en donde puede ser aplicado el parche.
    Un saludo.

    • El parche requiere la definición de CGROUPS y de gestión de memoria de la TTY, para poder implementarlo en 2.6.36 tendrías que parchear 2.6.36 para que 2.6.36 implemente “task groups” y es lo que *precisamente* hace el parche secundario que incorpora Mike Galbraith, uno, el scheduler auto-groups y el otro, que incorpora task groups en 2.6.36.
      Nota: ese parche (incorporar task groups a un kernel 2.6.36) fué diseñado por Mike Galbraith 2 días después del primer parche y por cierto, 2 días después de haber publicado este artículo.

      Es bueno que notes esto para los que lean este post puedan enterarse de los cambios …

      Saludos!

  11. Mira el final de la página #7 del foro de phoronix.
    Aquí el patch para la versión 2.6.36:
    https://patchwork.kernel.org/patch/337311/

    Saludos.

  12. Hola!

    Pregunta de un nabo… Qué podría pasar o generar si coloco este parche en un kernel con el parche de Con Kolivas?

    Salu2

    • Pues YO MISMO me he hecho la pregunta, en el sentido de que al ya existir el parche de Mike para 2.6.36 (el parche de Con Kolivas solo existe para < 2.6.36) se podrían mezclar ambos … un equipo con Task Groups dentro de un sistema de scheduler tipo Brain Fuck (BFS)? … sería interesantísimo verlo en acción! …

  13. Interesantísimo estoy por compilar el kernel para neonatox 0.6 y ya he conseguido el parche🙂..

    Muy buenas tus pruebas a ver si con esto el noveau me anda más rápido que con el kernel vanilla andaba muy bien.

    Saludos vieja!! xD

    • Pues que bueno que hayas conseguido el parche, combina esto con las mejoras de userspace del script de Lennart Poettering y con las mejoras en el sistema MTRR de video (ver otros posts en mi blog) y me cuentas como te mejora! …

      Exitos!

  14. http://www.huntingbears.com.ve/el-famoso-script-de-lennart-poettering-mejorado-en-hunting-bears.html

    Doña, échale un vistazo. Mejoré y corregí algunos errores del script que publicaron en UbuntuLife, además de dar una explicación proper.

  1. Pingback: Twitted by Geeks_Zone

  2. Pingback: Articulo Indexado en la Blogosfera de Sysmaya

  3. Pingback: Aplicar el “milagroso” parche del kernel sin recompilar. | Muy Trucos

  4. Pingback: Como instalar la versión en desarrollo de Canaima GNU/Linux 3.0 // Hunting Bears

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: