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 mrproperY la copia de las opciones “por defecto”
make oldconfigAhora 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 lzopEnable 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
update-grub2y 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:
- corrección del bug de MTRR
- Activación de la aceleración 3D y el direct-rendering de la Intel 965
- Re-configuración del Xorg para squeeze
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
No hay comentarios:
Publicar un comentario