Как прерывание ставится в очередь в Linux?

Обычно обработчики прерываний проектируются как можно более короткими, а фактический код обработки вызывается в контексте, -похожем на процесс. Обработчик просто определяет источник, добавляет запись в очередь в программном обеспечении и впоследствии отключает источник прерывания. Когда ЦП возвращается из обработки прерывания, сначала обрабатывается очередь обработчиков прерывания, затем возобновляется любой процесс, который является «текущим».

Обработчики, вызываемые во время оценки очереди, могут изменить, какой процесс является «текущим», наиболее очевидным примером является прерывание таймера, указывающее, что квант времени истек, но входящие события также могут запускать процессы с более высоким -приоритетом, что будет планировать их.

Многопроцессорные -системы имеют явную маршрутизацию прерываний, как правило, с выделенным таймером IRQ, который направляется только на связанный с ним ЦП, и аппаратные прерывания, имеющие либо «предпочтительный» ЦП (для улучшения локальности кэша ), либо к ним применяется подход балансировки нагрузки, при котором контроллер прерываний обеспечивает их распределение.

С аппаратной точки зрения прерывания всегда помечаются, а не ставятся в очередь, поэтому прерывание не может быть отправлено снова, пока оно не будет обработано (, поэтому нет аппаратного ограничения, при котором прерывания теряются, если скорость слишком высока ), но ОС обычно хранит очередь в программном обеспечении, поэтому она проводит как можно меньше времени в «реальном» обработчике IRQ (, а длина этой очереди ограничена, поскольку в очередь может быть поставлен только один экземпляр каждого источника ).

Таким образом, обработчик "нижней -половины", который взаимодействует с одним конкретным аппаратным обеспечением, может быть прерван другим входящим прерыванием, но все, что он делает, это добавляет второе прерывание в очередь. Затем возобновляется нижний обработчик -половины для первого прерывания, когда он возвращается, вызывается нижний обработчик -половины для второго прерывания, и как только очередь нижних -половинных обработчиков становится пустой,текущий пользовательский процесс -выполняется.

Нет гарантии на следующий запуск процесса. Каждый раз, когда обрабатывается прерывание, ядро ​​определяет, что следует запланировать следующим (процесс с более высоким приоритетом, который стал работоспособным, приоритет текущего процесса снизился, а очередь другого процесса увеличилась,... ). Содержимое кеша все равно снимается, поэтому нет особого смысла всегда возобновлять запущенный процесс. И то, что происходит, является строго внутренним делом ядра, используемая политика может измениться без предупреждения.