En los sistemas operativos , una tormenta de interrupciones es un evento durante el cual un procesador recibe una cantidad excesiva de interrupciones que consumen la mayor parte del tiempo del procesador. Las tormentas de interrupciones suelen estar causadas por dispositivos de hardware que no admiten la limitación de la tasa de interrupciones.
Debido a que el procesamiento de interrupciones es típicamente una tarea no preemptible en sistemas operativos de tiempo compartido , una tormenta de interrupciones causará una respuesta lenta a la entrada del usuario, o incluso parecerá congelar el sistema por completo. Este estado se conoce comúnmente como bloqueo activo . En tal estado, el sistema está gastando la mayoría de sus recursos procesando interrupciones en lugar de completar otro trabajo. Para el usuario final, no parece estar procesando nada en absoluto ya que a menudo no hay salida. Una tormenta de interrupciones a veces se confunde con thrashing , ya que ambos tienen síntomas similares (respuesta insensible o lenta a la entrada del usuario, poca o ninguna salida).
Las causas más comunes incluyen: hardware mal configurado o defectuoso, controladores de dispositivos defectuosos, fallas en el sistema operativo o metaestabilidad en uno o más componentes. Esta última condición rara vez ocurre fuera de un prototipo o hardware construido por aficionados.
La mayoría de los sistemas operativos y hardware modernos cuentan con métodos para mitigar el efecto de una tormenta de interrupciones. Por ejemplo, la mayoría de los controladores Ethernet implementan una "limitación de la tasa" de interrupciones, que hace que el controlador espere una cantidad de tiempo programable entre cada interrupción que genera. Cuando no está presente en el dispositivo, normalmente se incluye una funcionalidad similar en el controlador del dispositivo o en el propio sistema operativo.
La causa más común es cuando un dispositivo "detrás" de otro envía una señal de interrupción a un APIC (controlador de interrupciones programable avanzado). La mayoría de los periféricos de ordenador generan interrupciones a través de un APIC, ya que la cantidad de interrupciones es casi siempre menor (normalmente 15 en el caso de los PC modernos) que la cantidad de dispositivos. El sistema operativo debe consultar a cada controlador registrado en esa interrupción para preguntar si la interrupción se originó en su hardware. Los controladores defectuosos siempre pueden responder "sí", lo que hace que el sistema operativo no consulte a otros controladores registrados en esa interrupción (solo se puede procesar una interrupción a la vez). Por lo tanto, el dispositivo que solicitó originalmente la interrupción no obtiene su servicio, por lo que se genera una nueva interrupción (o no se elimina) y el procesador se ve inundado de señales de interrupción continuas. Cualquier sistema operativo puede quedarse bloqueado en una tormenta de interrupciones causada por una falla de este tipo. Un depurador de kernel generalmente puede romper la tormenta descargando el controlador defectuoso, lo que permite que el controlador "debajo" del defectuoso elimine la interrupción, si aún es posible la entrada del usuario.
Esto ocurría en una versión anterior de FreeBSD , donde las tarjetas PCI que estaban configuradas para funcionar en modo de compatibilidad ISA no podían interactuar correctamente con el enrutamiento de interrupciones ISA. Esto causaba que el sistema operativo nunca detectara las interrupciones o que el sistema operativo nunca pudiera eliminarlas, lo que resultaba en una tormenta de interrupciones. [1]
Como los controladores suelen ser implementados por un tercero, la mayoría de los sistemas operativos también tienen un modo de sondeo que consulta las interrupciones pendientes a intervalos fijos o de forma rotatoria. Este modo se puede configurar de forma global, por controlador, por interrupción o de forma dinámica si el sistema operativo detecta una condición de falla o una generación excesiva de interrupciones. Se puede habilitar un modo de sondeo de forma dinámica cuando la cantidad de interrupciones o el uso de recursos causado por una interrupción supera ciertos umbrales. Cuando ya no se superan estos umbrales, un sistema operativo puede cambiar el controlador de interrupción, la interrupción o el manejo de interrupciones de forma global, de un modo de interrupción a un modo de sondeo. La limitación de la tasa de interrupciones en el hardware generalmente niega el uso de un modo de sondeo, pero aún puede ocurrir durante el funcionamiento normal durante una E/S intensa si el procesador no puede cambiar de contexto lo suficientemente rápido como para mantener el ritmo.
Quizás la primera tormenta interrumpida ocurrió durante el descenso lunar del Apolo 11 en 1969. [2]
La limitación de la tasa de interrupciones debe configurarse cuidadosamente para obtener resultados óptimos. Por ejemplo, un controlador Ethernet con limitación de la tasa de interrupciones almacenará en búfer los paquetes que recibe de la red entre cada interrupción. Si la tasa se establece en un nivel demasiado bajo, el búfer del controlador se desbordará y se descartarán los paquetes. La tasa debe tener en cuenta la velocidad con la que se puede llenar el búfer entre interrupciones y la latencia de la interrupción entre la interrupción y la transferencia del búfer al sistema.
Existen enfoques basados en hardware y software para solucionar el problema. Por ejemplo, FreeBSD detecta tormentas de interrupciones y enmascara las interrupciones problemáticas durante un tiempo como respuesta. [ cita requerida ]
El sistema utilizado por NAPI es un ejemplo del enfoque basado en hardware: el sistema (controlador) se inicia en un estado de interrupción habilitada, y el controlador de interrupciones luego deshabilita la interrupción y permite que un hilo/tarea maneje el evento o los eventos y luego la tarea sondea el dispositivo, procesa una cierta cantidad de eventos y habilita la interrupción.
Otro enfoque interesante que utiliza soporte de hardware es aquel en el que el dispositivo genera una interrupción cuando el estado de la cola de eventos cambia de "vacío" a "no vacío". Entonces, si no hay descriptores DMA libres en la cola de la FIFO RX, el dispositivo descarta el evento. El evento se agrega a la cola y la entrada de la FIFO se marca como ocupada. Si en ese punto la entrada (cola −1) está libre (borrada), se generará una interrupción (interrupción de nivel) y se incrementará el puntero de cola. Si el hardware requiere que se reconozca la interrupción, la CPU (manejador de interrupciones) lo hará, manejará los descriptores DMA válidos en la cabecera y regresará de la interrupción.