Introducción al kernel-rt.

#1 por vagar el 18/08/2009
CAPÍTULO I

MULTITAREA

El kernel de Linux, como el de la mayoría de los sistemas operativos modernos, es multitarea. Eso quiere decir que se están ejecutando varios programas al mismo tiempo.

En realidad esto no ocurre exactamente así. Lo que se hace es poner los programas en una cola y, uno por uno, el microprocesador los ejecuta durante una cierta cantidad de tiempo. Una vez agotado éste el microprocesador interrumpe la tarea dejándola a medias y da paso a la siguiente. A esta cantidad de tiempo se le denomina quantum o time slice, y no tiene por qué ser constante.

Una buena analogía podría ser el cocinero de un bar preparando varios platos a la vez: un bocata de lomo, una de callos, una ensalada mixta... Ahora parto el pan, enciendo la sartén, mientras se calienta lavo la lechuga, etc.

Si el quantum es suficientemente pequeño la impresión subjetiva para un observador lento, como el ser humano, es de que en vez de un procesador rápido ejecutando tareas alternativamente tenemos un procesador lento para cada una ellas (varios cocineros en la misma cocina haciendo lentamente cada uno un solo plato).

LA CONMUTACIÓN DE TAREAS TIENE UN COSTE

La multitarea no es gratis: implica una sobrecarga del procesador. En efecto, desalojar una tarea y cargar la siguiente es un trabajo extra. Esta operación se denomina 'cambio de contexto' o 'conmutación de tareas'. Sería más rentable en términos de CPU ejecutar los programas por completo, uno por uno, que partirlos en 'rodajas' e ir saltando de uno a otro. Sin embargo, el sistema perdería en interactividad, no podríamos tener varias ventanas abiertas o, en el caso de un servidor, atender a varias peticiones simultáneamente.

LATENCIA Y RENDIMIENTO

Supongamos que nuestro cocinero tiene que pelar 20 kilos de gambas y deshuesar 20 kilos de aceitunas. ¿Cómo se planifica el trabajo?

En un caso extremo primero pelaría todas las gambas, se lavaría las manos para no mezclar sabores y después deshuesaría todas las aceitunas. Lo representaremos así:

GGGGGGGGGGGGGGGGGGGGGG... C AAAAAAAAAAAAAAAAAAAAAA...

En el extremo opuesto, pelaría una gamba, se lavaría las manos, deshuesaría una aceituna, se lavaría las manos... gamba, aceituna, gamba, aceituna... Lo representaremos así:

GCACGCACGCACGCACGCACGCACGCACGCACGCACGCACGCACGCACGCACGCACGCAC...

La 'C' representa el cambio de contexto: lavarse las manos, cambiar de utensilio...

Al mismo tiempo, un camarero recoge las peticiones de los clientes: "¡una de gambas!"... "¡una de aceitunas!"... y las translada a la cocina.

En el primer caso, supongamos que entra un cliente y pide una ración de gambas. No hay problema, enseguida se le sirve. Pero, ¿y si pide aceitunas? El camarero no podría servirla hasta que todas las gambas estuvieran peladas. En este caso la latencia, que es el tiempo que pasa desde que se hace una petición hasta que ésta es atendida, sería muy alta.

En el segundo caso, pida lo que pida el cliente, estará disponible en poco tiempo, además prácticamente igual en ambos casos. La latencia será baja, pero a un coste: debido a los cambios de contexto se producirá una disminución del rendimiento, entendido como la parte del tiempo durante el cuál la CPU está haciendo tareas directamente productivas, en lugar de labores de soporte.

Evidentemente en este caso la solución ideal sería un término medio, que dependería del tamaño de las raciones y de la distribución estadística de las peticiones. La teoría de colas es la rama de la matemática que se encarga de estudiar estas situaciones y de darles soluciones óptimas.

Como se puede ver, latencia y rendimiento son opuestos. Por esta razón no es correcto afirmar que los kernels rt dan más rendimiento. Todo lo contrario, al bajar la latencia empeoran el rendimiento de la máquina y, por lo tanto, son una elección pésima para sistemas que no necesiten respuestas superrápidas como, por ejemplo, servidores web o de bases de datos.

Por el contrario, los kernels de baja latencia son ideales en situaciones donde se necesite la máxima velocidad de respuesta a los estímulos externos, como sistemas de control industrial o aplicaciones multimedia interactivas, sabiendo que estamos sacrificando parte de la potencia de la máquina en garantizar esa rápida reacción.

PRIORIDADES

Una opción interesante en sistemas multitarea es dar distintas prioridades a las tareas, de tal forma que las más importantes reciban más tiempo del procesador y las menos importantes menos. En un kernel normal esto se hace con el comando 'nice'. Si nuestro cocinero espera servir más raciones de gambas que de aceitunas haría bien en dedicarle más tiempo a las primeras, lógicamente.

LOS KERNELS RT

El problema de los kernel normales es que las tareas no se pueden interrumpir en cualquier sitio, hay que esperar a que lleguen a ciertos puntos de ejecución donde ya se pueden detener para conmutar a otra. Esto introduce lo que llamamos latencia.

Por ponerlo de una forma simplificada, los kernels rt permiten interrumpir las tareas en más cantidad de sitios que los kernel normales. Pueden hacer, por así decirlo, rodajas más finas de tiempo, así que la tarea actual será desalojada más rápidamente y nuestra tarea prioritaria podrá acceder antes a la CPU. Por lo tanto la latencia será más baja.

Digamos que un kernel rt nos permite dejar una gamba a medio pelar si lo que se necesita en ese momento, urgentemente, es ponerse a deshuesar una aceituna lo antes posible, mientras que en un kernel normal habría que terminar de pelar la gamba.

Además de hacer rodajas más finas, los kernels rt tienen un sistema de prioridades mucho más estricto, donde las tareas prioritarias pegan hachazos inmisericordes a las demás (preempting) para hacerse con el control de la CPU, ralentizando los demás programas lo que sea necesario para cumplir con sus requisitos.

¿CUANDO ES IMPORTANTE UN KERNEL RT?

En dos casos:

1) Cuando necesitamos latencias muy bajas, es decir, reacciones muy rápidas de la máquina. El ejemplo más claro es la ejecución de instrumentos virtuales, donde necesitas que al pulsar una tecla de un teclado MIDI el instrumento suene inmediatamente.

2) Cuando necesitamos prioridades muy estrictas, es decir, que nuestra tarea de alta prioridad no se interrumpa por nada del mundo (a no ser en el caso catastrófico de que la CPU esté tan sobrecargada que se supere el 100% de utilización). Por ejemplo, estamos grabando una sesión de audio con Ardour y observando como suben y bajan los indicadores de los faders. No importa si perdemos algún cuadro de refresco de los faders con tal de que el transporte de sonido del micrófono al disco duro no se vea interrumpido. Un kernel rt ralentizará el refresco de los faders todo lo que sea necesario con tal de que no se pierda ni una muestra de audio.

Dicho esto, en general los kernels no rt más recientes han mejorado mucho su sistema de planificación de tareas y su gestión de prioridades. Si no tienes la CPU al límite de sus posibilidades (digamos por debajo del 50% de utilización) o si no te importa que de vez en cuando se produzca un pequeño microcorte (clic) en el sonido (los tan temidos xruns), un kernel normal da unas prestaciones perfectamente aceptables.

¿QUÉ LATENCIA ES ACONSEJABLE?

A mí personalmente cualquier cosa por debajo de 10 ms ya me va bien y a partir de 20 ms ya empiezo a notar el retardo claramente. Hay gente más exigente. O menos. Como cosa curiosa, los organistas de iglesia son capaces de tocar maravillosamente aún teniendo unas latencias brutales.



Otro día os cuento más sobre configuración del kernel rt.

(c) 2009 Luis Garrido
Este texto se publica bajo una licencia Creative Commons Attribution-Noncommercial-No Derivative

Ars longa, vita brevis.
Mi colección de enlaces web en diigo.

Subir
#2 por catorze el 19/08/2009
BRAVO!
Subir
#3 por Pablo_F el 20/08/2009
Gracias Luis. Muy educativo. Se agradece que empieces desde cero ya que muchos somos autodidactas y nos faltan las bases más elementales. ¡Esperando el capítulo 2!

Saludos. Pablo
Subir
#4 por igny el 20/08/2009
Enhorabuena Luis. Sigue dándonos más "recetas" =D>

Muchas gracias y esperamos la segunda.

Saludos
Subir
1
--84263--
#5 por --84263-- el 21/08/2009
gracias luis....esperando que cuentes mas sobre este "dichoso kernel",perdon..gracias luis
salut y alegria
Subir
#6 por vagar el 04/11/2009
Siguiendo con el tema del kernel-rt, para sacarle el mejor partido hay que organizar las prioridades de las rutinas de atención a interrupciones, de lo contrario estamos desaprovechando gran parte de su potencial. Aquí os dejo un enlace a un artículo en inglés de Jörn Nettingsmeier donde explica un poco el asunto.

http://subversion.ffado.org/wiki/IrqPriorities

Es importante destacar el cambio que se ha introducido en la versión 2.6.31 del kernel, que permite discriminar entre los distintos periféricos que comparten una línea de interrupción asignándoles prioridades distintas.

Ars longa, vita brevis.
Mi colección de enlaces web en diigo.

Subir
#7 por Ismael Valladolid Torres el 26/11/2009
Estimado Luis, crack entre los cracks:

-- Hay más información y en español sobre el ajuste de prioridades de las IRQs en [1]este artículo en mi blog Linux AV. Te recomiendo que sigas las actualizaciones de mi blog para que no dupliquemos esfuerzos si no es necesario. :D

1. http://bit.ly/7DRlWL

-- ¿Puedo contar con tu autorización para publicar en el blog aquello que compartas en el foro con licencia CC aunque tu licencia sea no comercial y el blog en un momento dado pueda incorporar banners publicitarios?

Muchísimas gracias figura.

Sígueme en Twitter

Subir
#8 por vagar el 26/11/2009
Hola, Ismael.

Encantado de que mis posts se incorporen a tu blog. He visto que agregas cosas de otros blogs, traduces, etc. Me parece un recurso estupendo. Incluyo tu blog en mi agregador RSS para estar al tanto.

Gracias por tu contribución a la comunidad. Un cordial saludo,

Luis

Ars longa, vita brevis.
Mi colección de enlaces web en diigo.

Subir
#9 por Ismael Valladolid Torres el 04/01/2010
http://www.linuxav.net/index.php/2010/0 ... -realtime/

¡Una entrada fantástica! ¡Gracias Luis!

Sígueme en Twitter

Subir
#10 por monon el 07/01/2010
Me gustaria saber un par de cosillas si es que alguien sabe las respuestas , claro está.
Uso Ubuntu 9.10 para 64bits como distro principal y parece que han cambiado varias cosas con respecto a versiones anteriores y a otras distros.
La primera, p.e., es que cuando quiero saber las prioridades de los procesos IRQ
el resultado de
[code]ps -eLo pid,cls,rtprio,pri,nice,cmd | grep -i "irq"[/code]
es tan solo esto:
[code] 4 TS - 24 -5 [ksoftirqd/0]
7 TS - 24 -5 [ksoftirqd/1][/code]
en vez de algo así:
[code] 3 FF 49 89 - [sirq-high/0]
4 FF 49 89 - [sirq-timer/0]
5 FF 49 89 - [sirq-net-tx/0]
6 FF 49 89 - [sirq-net-rx/0]
7 FF 49 89 - [sirq-block/0]
8 FF 49 89 - [sirq-tasklet/0]
9 FF 49 89 - [sirq-sched/0]
10 FF 49 89 - [sirq-hrtimer/0]
11 FF 49 89 - [sirq-rcu/0]
24 FF 50 90 - [irq/9-acpi]
33 FF 50 90 - [irq/12-i8042]
34 FF 50 90 - [irq/1-i8042]
68 FF 50 90 - [irq/14-ata_piix]
69 FF 50 90 - [irq/15-ata_piix]
293 FF 50 90 - [irq/19-ehci_hcd]
...
...[/code]
osea solo aparece ksoftirqd en vez de toda la lista de interrupciones.
¿Alguien sabe por que razón? o ¿Hay algun otro modo de averiguar esas prioridades?

Otra de las preguntas es
¿Donde está /proc/sys/dev/rtc/max-user-freq?¿No existe más?
Por que ahí no esta (/proc/sys/dev/rtc)
Lo maximo que he encontrado es en /proc/sys/kernel
sched_child_runs_first sched_nr_migrate
sched_compat_yield sched_rt_period_us
sched_domain/ sched_rt_runtime_us
sched_features sched_shares_ratelimit
sched_latency_ns sched_shares_thresh
sched_migration_cost sched_wakeup_granularity_ns
sched_min_granularity_ns

Y por ultima
¿Por que razon el kernel rt de ubuntu está tan descuidado? :cry:
Es el mas inestable de cuantos he probado en mi vida. Y con una diferencia de version con respeto a los genericos que da pena. Ya se que aquí nadie tiene la culpa, pero me lo sigo preguntando.

Pues de entre los millones de cosas que quisiera saber, de momento solo eso.
Gracias ya de antemano.
Subir
#11 por monon el 07/01/2010
Perdonad algunas de las preguntas quedan autocontestadas por mi propia estupidez.
No habia iniciado con kernel -rt sino con -generic.
Pero la ultima pregunta sigue en pie.
Subir
#12 por monon el 07/01/2010
Bueno como comenta lgarrido un poco mas arriba han cambiado las cosas en el kernel 2.6.31 lo que hace que los nombres de los procesos hayan cambiado tambien, por lo que el comando pidof no funcione como era de esperar usandolo para cambiar las prioridades.
[code]chrt -f -p 95 `pidof "IRQ-8"`[/code]
por lo que si a alguien le sirve lo puede cambiar por
[code]chrt -f -p 95 `ps --no-headers -o pid -C irq/8-rtc0`[/code]
donde hay que cambiar irq/8-rtc0 por el nombre del proceso al que queramos cambiar la prioridad.
Puede que os sirva si realizais el cambio de prioridades dede un script.
Subir
#13 por tonixd el 09/10/2013
Excelente!!! Pocas veces me explicaron algo tan bien...
Aunque ya pasaron unos años desde que este thread está creado supongo que la información sigue siendo válida.
Estoy incursionando en ubuntu para usar audio, si me va bien como está genial, ahora le tengo más confianza al kernel normal gracias a tu explicación. Solo si es absolutamente necestario me voy a pasar a un kernel RT. Mil gracias!

He ain't got no distractions, an't hear those buzzers and bells,
don't see lights a flashing, plays by sense of smell.
Always has a replay and never tilts at all.
That deaf dumb and blind kid sure plays a mean pinball.

Subir
Respuesta rápida

Regístrate o para poder postear en este hilo