В операционных системах , прерывание шторм этого событие , в течение которого процессор получает чрезмерное количество прерываний , которые потребляют большую часть времени процессора. Штормы прерываний обычно вызываются аппаратными устройствами, которые не поддерживают ограничение частоты прерываний.
Задний план
Поскольку прерывание обработки обычно представляет собой не- прерываться задача в режиме разделения времени операционных систем , прерывание шторм вызовет вялый ответ на пользовательский ввод, или даже , по всей видимости заморозить полностью систему. Это состояние обычно известно как активная блокировка . В таком состоянии система тратит большую часть своих ресурсов на обработку прерываний вместо выполнения другой работы. Конечному пользователю кажется, что он вообще ничего не обрабатывает, так как часто нет вывода. Шторм прерываний иногда ошибочно принимают за перегрузку , поскольку они оба имеют схожие симптомы (отсутствие реакции или медленная реакция на ввод данных пользователем, небольшой вывод или отсутствие вывода).
К распространенным причинам относятся: неправильно настроенное или неисправное оборудование, неисправные драйверы устройств, недостатки операционной системы или метастабильность в одном или нескольких компонентах. Последнее условие редко встречается за пределами прототипа или оборудования любительской сборки.
У большинства современного оборудования и операционных систем есть методы смягчения эффекта шторма прерываний. Например, большинство контроллеров Ethernet реализуют «ограничение скорости» прерывания, которое заставляет контроллер ждать программируемое время между каждым генерируемым прерыванием. Если подобные функции отсутствуют в устройстве, они обычно записываются в драйвер устройства и / или в саму операционную систему.
Наиболее частая причина - когда устройство «позади» другого сигнализирует о прерывании APIC (Advanced Programmable Interrupt Controller). Большинство компьютерных периферийных устройств генерируют прерывания через APIC, поскольку количество прерываний всегда меньше (обычно 15 для современных ПК), чем количество устройств. Затем ОС должна запросить каждый драйвер, зарегистрированный для этого прерывания, чтобы узнать, исходит ли прерывание от ее оборудования. Неисправные драйверы всегда могут заявить «да», в результате чего ОС не будет опрашивать другие драйверы, зарегистрированные для этого прерывания (одновременно может обрабатываться только одно прерывание). Следовательно, устройство, которое первоначально запросило прерывание, не получает обслуживания прерывания, поэтому генерируется новое прерывание (или не сбрасывается), и процессор оказывается завален непрерывными сигналами прерывания. Любая операционная система может заблокироваться во время шторма прерываний, вызванного такой ошибкой. Ядро отладчик обычно может сломать шторм выгружать неисправный драйвер, что позволяет водителю «под» неисправной очистить прерывание, если пользовательский ввод еще возможен.
Поскольку драйверы чаще всего реализуются сторонними организациями, большинство операционных систем также имеют режим опроса, который запрашивает ожидающие прерывания через фиксированные интервалы или в циклическом режиме. Этот режим может быть установлен глобально, для каждого драйвера, для каждого прерывания или динамически, если ОС обнаруживает состояние сбоя или генерацию чрезмерного прерывания. Режим опроса может быть включен динамически, когда количество прерываний или использование ресурсов, вызванное прерыванием, превышает определенные пороговые значения. Когда эти пороговые значения больше не превышаются, ОС может изменить драйвер прерывания, прерывание или обработку прерывания глобально, с режима прерывания на режим опроса. Аппаратное ограничение частоты прерываний обычно сводит на нет использование режима опроса, но все же может произойти во время нормальной работы во время интенсивного ввода-вывода, если процессор не может переключать контексты достаточно быстро, чтобы идти в ногу.
История
Возможно, первая прерывистая буря произошла во время спуска Аполлона-11 на Луну в 1969 году. [1]
Соображения
Для получения оптимальных результатов необходимо тщательно настроить ограничение частоты прерываний. Например, контроллер Ethernet с ограничением частоты прерываний будет буферизовать пакеты, которые он получает из сети, между каждым прерыванием. Если скорость установлена слишком низкой, буфер контроллера переполнится, и пакеты будут отброшены. Скорость должна учитывать, насколько быстро буфер может заполняться между прерываниями, и задержка прерывания между прерыванием и передачей буфера в систему.
Снижение прерывания
Есть аппаратный и программный подходы к решению проблемы. Например, FreeBSD обнаруживает шторм прерываний и на некоторое время маскирует проблемные прерывания в ответ. [ необходима цитата ]
Система, используемая NAPI, является примером аппаратного подхода: система (драйвер) запускается в состоянии включения прерывания, а обработчик прерывания затем отключает прерывание и позволяет потоку / задаче обрабатывать событие (я), а затем опрашивает задачу. устройство, обрабатывающее некоторое количество событий и разрешающее прерывание.
Другой интересный подход с использованием аппаратной поддержки - это тот, где устройство генерирует прерывание, когда состояние очереди событий изменяется с «пусто» на «не пусто». Затем, если в хвосте RX FIFO нет свободных дескрипторов DMA, устройство отбрасывает событие. Затем событие добавляется в хвост, и запись FIFO помечается как занятая. Если в этой точке вход (хвост-1) свободен (очищен), будет сгенерировано прерывание (прерывание по уровню), и указатель хвоста будет увеличен. Если аппаратное обеспечение требует подтверждения прерывания, ЦП (обработчик прерывания) сделает это, обработает действительные дескрипторы DMA в голове и вернется из прерывания.
Смотрите также
Рекомендации
- ^ Мюррей, Чарльз (1989). Аполлон: Гонка на Луну . Саймон и Шустер. С. 345–355.