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
- mkiniramfs -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.
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.
Fuente:
phenobarbital.wordpress.com
