Manejo de Interrupciones en Linux

M anejo anejo de I nterr nterr upciones upciones en L in ux

 Al igual que los sistemas Unix tradicio nales, las versiones del núcleo de Linux (previas a la versión 2.6) son no expropiables y también se pueden dividir en dos mitades: una mitad no dirigida por interrupción (“non-interrupt (“non-interrupt half ”) ”) que es activada de forma procedural por las llamadas al sistema (que se corresponde con el “ top half ” de BCD) y la otra mitad dirigida por interrupción (“interrupt (“interrupt half ”) ”) que contiene el código que se ejecuta comoparte de las peticiones de interrupción (y se corresponde con el “bottom “ bottom half ” de BSD). Igual que en los sistemas Unix clásicos, ninguna interrupción que se reciba mientras un proceso (o hilo) está ejecutando el código de un servicio del núcleo, provoca una replanificación de forma directa; en su lugar, se activa la bandera del núcleo need_resched para solicitarle al núcleo que ejecute el planificador luego de que se haya completado la llamada al sistema y se esté por devolver el control al modo usuario. Los procesos (o hilos) utilizan el mismo mecanismo de sincronización con eventos basado en el esquema de dormirse/despertarse. La sincronización entre el código de la mitad no dirigida por interrupción y el código de las ISRs se realiza de igual modo mediante la inhabilitación temporal de las interrupciones durante el acceso a las estructuras de datos compartidas.  Al igual que otros sistemas operativos de r ed, Linux implementa una arquitectura estándar de manejo de interrupciones en dos niveles dividiendo el servicio a las interrupciones en dos secciones: la mitad superior (“Top (“Top half ”) ”) constituida por la ISR que recibe la interrupción de hardware y la mitad inferior (“Bottom (“Bottom half ”) ”) que hace el grueso del procesamiento de la petición de forma diferida con todas las interrupciones habilitadas . La arquitectura de bottom half original se mantuvo sin modificaciones hasta la versión Linux 2.2. Sin embargo, debido a que el diseño original de Linux se hizo para máquinas con una sola CPU, esta arquitectura de bottom half se convirtió en un cuello de botella en arquitecturas con múltiples CPU. El problema era que aunque cada una de las CPU podía manejar una interrupción (“top (“top half ”) ”) a la vez, la capa de bottom half era de simple hilo, de modo que el procesamiento diferido por todas las ISRs no se podía distribuir entre todas las CPUs. En consecuencia, para la versión 2.3 se introdujo el soporte de multiprocesamiento simétrico o SMP (“Symmetric (“Symmetric Multiprocessors”) Multiprocessors”) en los bottom halves. halves. Esto se llevó a cabo reemplazando los bottom halves originales originales con los denominados “softirq “ softirq”” y “tasklets “tasklets”. ”. Una softirq representa una petición para que una función específica se ejecute en algún instante futuro. Si el mismo tipo de softirq se solicita múltiples veces entonces las invocaciones de esta se pueden ejecutar de forma concurrente en múltiples procesadores. Por el contrario, diferentes tasklets pueden ejecutarse simultáneamente en múltiples CPUs, pero las invocaciones de la misma tasklet son serializadas con respecto a si mismas. Por razones de compatibilidad, los bottom halves del viejo estilo se volvieron a implementar utilizando un conjunto de tasklets que se ejecutaban reteniendo un cierre de giro (“spinlock  (“spinlock ”) ”) global dedicado de modo que cuando uno se está ejecutando en alguna CPU, ningún otro se puede ejecutar en alguna otra CPU.  Aunque el diseño anterior preservó la compatibil idad con los manejadores de dispositivos legados, todavía le imponía una fuerte restricción al desempeño de Linux 2.4 en sistemas multiprocesador. Para la versión Linux 2.5 los bottom halves del viejo estilo fueron eliminados y todo el código que lo usaba se modificó para usar ya sea softirqs o tasklets. tasklets .  Actualmente el término “Bott om Half” se usa para referirs e a cualquiera de los código diferibles (sea softirq o un tasklet ). ). En Linux 2.6 se introdujo otro esquema para planificación de funciones diferidas al que se le denomina colas de trabajo (“workqueues (“ workqueues”) ”) y que como diferencias más importantes con

las funciones diferibles antes mencionadas se ejecutan en el contexto de hilos del núcleo. La Figura 10 muestra un resumen de estos mecanismos de ejecución diferida de Linux.

I nterr upciones manejadas como hi los en los sistemas L in ux para T iempo Real

Motivados por la necesidad de hacer que el núcleo de Linux fuese más sensible (“responsive”) a los eventos externos de modo que fuese adecuado para aplicaciones con requerimientos de tiempo, muchos trabajos le han realizado mo dificaciones para introducirle el tratamiento de interrupciones (exceptuando la ISR del R eloj) en el contexto de hilos del núcleo. Estas modificaciones han t enido el propósito de reducir la latencia de expropiación, la cual puede ser muy elevada en Linux (superior a los 100 ms). Estos trabajos estuvieron precedidos por los primeros enfoques para introducir la expropiación al núcleo de Linux: los parches de expropiación y los parches de baja latencia. Las primeras implementaciones de estos parches protegían las secciones críticas dentro del núcleo mediante cierres de expropiación (“ preemption locks”) que inhabilitaban la expropiación durante las mismas. El siguiente paso fue sustituir los cierres de expropiación por mutexes de modo que la expropiación fuese posible incluso mientras el núcleo está dentro de una sección crítica. Estas técnicas lograron reducir significativamente la latencia de expropiación con respecto al núcleo de Linux convencional; sin embargo todavía no logran obtener valores suficientemente bajos. La razón de ello es que con estas técnicas no es posible la expropiación mientras se está ejecutando una ISR o incluso los manejadores de segundo nivel. Un problema aún mayor es que, a pesar de que la arquitectura de interrupciones en dos niveles permite posponer el grueso del procesamiento de una interrupción a los manejadores diferidos. Todavía los tiempos de ejecución de los manejadores de primer nivel o ISRs difieren significativamente de una interrupción a otra. Como las ISRs se ejecutan con las interrupciones inhabilitadas todavía se hac e muy difícil predecir el tiempo máximo durante el cual las interrupciones están inhabilitadas. La solución a estas dificultades consistió en ejecutar los manejadores de interrupción en su  propio contexto de hilos del núcleo. Bajo este esquema, todas las interrupciones (excepto la del temporizador) se dirigen hacia un manejador de bajo nivel en el núcleo cuyo único  propósito es despertar a un hilo del núcleo correspondiente a la interrupción que  previamente está durmiendo. Este hilo puede entonces ser ejecutado posteriormente con todas las interrupciones habilitadas y bajo el control del planificador de hilos. Los hilos del núcleo dedicados al manejo de interrupción se pueden planificar en la clase de planificación

de tiempo real (SCHED_FIFO) permitiendo además asignarles prioridades inferiores a las de los hilos convencionales de tiempo real. Este esquema de interrupciones manejadas como hilos logra reducir la latencia de expropiación de tres formas: 1) Al permitir que los manejadores de interrupción se duerman, es posible reemplazar los cierres combinados de cierres de giro e interrupciones convencionales de Linux por mutexes que implementan el protocolo de herencia de prioridad permitiendo la expropiación de estas regiones críticas. 2) Como los hilos del núcleo destinados al man ejo de interrupciones son expropiables, si llega una interrupción de mayor prioridad mientras se está ejecutando el hilo del núcleo, el hilo de ISR con mayor prioridad puede expropiar al de menor prioridad. 3) Todas las interrupciones ejecutan una ISR común que da el mismo servicio y consume el mismo tiempo de ejecución para todas las interrupciones. De este modo, se puede restringir la latencia de interrupción a un período fijo y corto.