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 ser causadas por dispositivos de hardware que no admiten la limitación de la tasa de interrupciones.
Fondo
Debido a la interrupción de procesamiento es típicamente un no con derecho preferente de tarea en tiempo compartido sistemas operativos , una tormenta de interrupción provocará lenta respuesta a la entrada del usuario, o incluso parece congelar el sistema por completo. Este estado se conoce comúnmente como bloqueo en vivo . En tal estado, el sistema gasta la mayor parte 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 una paliza , ya que ambos tienen síntomas similares (respuesta inactiva o lenta a la entrada del usuario, poca o ninguna salida).
Las causas comunes incluyen: hardware mal configurado o defectuoso, controladores de dispositivos defectuosos, fallas en el sistema operativo o metaestabilidad en uno o más componentes. La última condición rara vez ocurre fuera del prototipo o del hardware construido por aficionados.
La mayoría de los sistemas operativos y hardware modernos tienen 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 velocidad" de interrupciones, lo que hace que el controlador espere una cantidad de tiempo programable entre cada interrupción que genera. Cuando no está presente en el dispositivo, una funcionalidad similar generalmente se escribe en el controlador del dispositivo y / o en el sistema operativo mismo.
La causa más común es cuando un dispositivo "detrás" de otro indica una interrupción a un APIC (controlador de interrupción programable avanzado). La mayoría de los periféricos de computadora generan interrupciones a través de un APIC, ya que la cantidad de interrupciones es siempre menor (generalmente 15 para la PC moderna) que la cantidad de dispositivos. Luego, el sistema operativo debe consultar cada controlador registrado en esa interrupción para preguntar si la interrupción se originó en su hardware. Los controladores defectuosos siempre pueden decir "sí", lo que hace que el sistema operativo no consulte a otros controladores registrados para 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 recibe su servicio de interrupción, por lo que se genera una nueva interrupción (o no se borra) y el procesador se inunda con señales de interrupción continuas. Cualquier sistema operativo puede bloquear en vivo bajo una tormenta de interrupciones causada por tal falla. Un depurador de kernel normalmente puede romper la tormenta descargando el controlador defectuoso, permitiendo que el controlador "debajo" del defectuoso borre la interrupción, si la entrada del usuario aún es posible.
Como los controladores son implementados con mayor frecuencia por terceros, la mayoría de los sistemas operativos también tienen un modo de sondeo que consulta las interrupciones pendientes a intervalos fijos o en forma de turnos. Este modo se puede configurar globalmente, por controlador, por interrupción o dinámicamente si el sistema operativo detecta una condición de falla o una generación excesiva de interrupciones. Un modo de sondeo puede habilitarse dinámicamente cuando el número de interrupciones o el uso de recursos causado por una interrupción supera ciertos umbrales. Cuando estos umbrales ya no se superan, un sistema operativo puede cambiar el controlador de interrupción, interrumpir o interrumpir el manejo globalmente, de un modo de interrupción a un modo de sondeo. La limitación de la tasa de interrupción en el hardware generalmente niega el uso de un modo de sondeo, pero aún puede suceder durante el funcionamiento normal durante una E / S intensa si el procesador no puede cambiar de contexto lo suficientemente rápido para mantener el ritmo.
Historia
Quizás la primera tormenta de interrupción ocurrió durante el descenso lunar del Apolo 11 en 1969. [1]
Consideraciones
La limitación de la tasa de interrupción debe configurarse cuidadosamente para obtener resultados óptimos. Por ejemplo, un controlador Ethernet con limitación de velocidad de interrupción almacenará en búfer los paquetes que recibe de la red entre cada interrupción. Si la velocidad es demasiado baja, el búfer del controlador se desbordará y los paquetes se descartarán. La tasa debe tener en cuenta qué tan rápido 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.
Interrupción mitigante
Existen enfoques del problema basados en hardware y software. Por ejemplo, FreeBSD detecta tormentas de interrupciones y enmascara las interrupciones problemáticas durante algún tiempo en respuesta. [ cita requerida ]
El sistema utilizado por NAPI es un ejemplo del enfoque basado en hardware: el sistema (controlador) se inicia en el estado de interrupción habilitada, y el controlador de interrupciones luego deshabilita la interrupción y permite que un hilo / tarea maneje los eventos y luego las encuestas de tareas el dispositivo, procesando cierto número de eventos y habilitando la interrupción.
Otro enfoque interesante que utiliza el soporte de hardware es uno 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". Luego, si no hay descriptores DMA libres en la cola RX FIFO, el dispositivo descarta el evento. Luego, el evento se agrega a la cola y la entrada FIFO se marca como ocupada. Si en ese punto la entrada (tail − 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.
Ver también
Referencias
- ^ Murray, Charles (1989). Apolo: La carrera hacia la luna . Simon y Schuster. págs. 345–355.