Как прерывания обрабатываются SMP?

Ответ 1

В многоядерных/многопроцессорных архитектурах APO APIC используется для маршрутизации прерываний на ядра/процессоры. Как следует из названия, APIC могут быть запрограммированы на выполнение маршрутизации по желанию.

Что касается синхронизации ядра: это зависит от ядра/ОС. Вы можете либо использовать схему с блокировкой (хотя IPI могут потребоваться на не кэшеориентированных архитектурах), либо вы также можете использовать предлагаемый подход к запуску ядра на каждом ядре и использовать некоторую явную межъядерную связь.

Barrelfish - пример операционной системы с несколькими ядрами. Если вас интересует архитектура такого типа, вы можете прочитать статью " Multikernel: новая архитектура ОС для масштабируемых многоядерных систем "

Ответ 2

Ну, это зависит от конкретной архитектуры, но из того, что я помню из документов Intel...

Существует два основных источника прерываний:

• Внутренний: они генерируются самим процессором. Включает ошибки, ловушки, программные прерывания и т.д.
• Внешние: это аппаратные прерывания, создаваемые периферийными устройствами.

Внутренние прерывания всегда доставляются на процессор, который сгенерировал его. Внешние отправляются в ядро ​​arbirary.

В современных моделях прерывания также могут быть доставлены с использованием подобной шине системы вместо старого управляемого прерывания, но я игнорирую, если эта модель используется в любой текущей ОС.

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

О последовательности в вашем примере:

• Ошибка страницы перенаправляется на ядро, которое сгенерировало его.
• Ядро обновляет свои таблицы MMU, которые защищены общей блокировкой или похожими.
• Нет, есть только одно ядро, обычно, если вы не примените модель виртуализации.
• Они синхронизируются с использованием общей блокировки или аналогичной структуры. Если оба ядра происходят с ошибкой на одной и той же странице в то же время... ну, на самом деле это неважно.

Ответ 3

Каждый процессор имеет свой собственный блок управления памятью с буфером поиска перевода. Это необходимо, потому что каждое ядро ​​может выполнять другой процесс, который имеет другое адресное пространство.

Несколько ядер могут независимо обрабатывать прерывания/исключения одновременно. Таким образом, одновременно может выполняться несколько параллельных контекстов прерываний, выполняемых в ядре.

Исключение, такое как ошибка страницы или деление на ноль, всегда будет обрабатываться на том же процессоре, на котором он произошел, поскольку он относится к тому, что делает этот процессор.

Внешние прерывания обычно проходят через какую-то коммутационную структуру, которая позволяет им каким-то образом сопоставлять процессоры, статически или динамически. Например. "APIC" на аппаратном уровне ПК.

Если ткань достаточно сложна, тогда прерывания могут быть перепрограммированы на разные ядра на лету.

Это зависит от архитектуры. Простейшая архитектура могла бы, например, связать все внешние прерывания с одним ядром. Это было бы не очень симметрично; это не допустило бы балансировку нагрузки IRQ.

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

Ответ 4

Каждый логический ЦП (т.е. ядро ​​ЦП) имеет собственный регистр cr3, обрабатывающий указатель на структуры поискового вызова. Возможны две ошибки страницы:

• в потоках одного процесса
• в потоках различных процессов.

Если это потоки разных процессов, то это не проблема. Я не знаю, что такое конкретная реализация Linux (да, я знаю, что она помечена как "linux" ), но есть два общих алгоритма управления виртуальной памятью в среде SMP:

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

Тот же код (обработчик #PF) может выполняться одновременно на двух разных ядрах, что не является проблемой. Если потоки используют два разных VASES ¹ то их ошибки страниц обрабатываются симметрично. Если ошибки страницы возникают в одном VAS, это все равно не проблема, пока #PF не будут вызваны доступом к той же странице. В таком случае каждая страница в VAS должна быть защищена спин-блокировкой (или просто #PF в данном VAS может быть защищена с помощью одной блокировки - таким образом, уменьшаются издержки памяти, но исключается возможность одновременного запуска двух обработчиков #PF).

В соответствии с этим ответом, только в системах NUMA, у каждого ядра ЦП есть собственный MMU; в других системах каждый физический процессор имеет собственный MMU, а также TLB для обработки различных структур подкачки, на которые ссылаются разные значения регистра cr3.

<суб > 1. VAS = виртуальное адресное пространство

Ответ 5

Я не получил "несколько экземпляров ядра", как правило, все правила ядра em. это означает, что у него нет экземпляра, вместо этого нужно думать о ядре как глобальной реактивной системе, которая предоставляет услуги приложениям.

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

** EDIT: после просмотра других комментариев мой ответ может быть устаревшим: в любом случае вы должны проверить: http://www.xml.com/ldd/chapter/book/ch13.html