11.1.2. Поддержка многопроцессорной в операционных системах

Рассмотрим подходы к реализации поддержки многопроцессорности в ОС на программном уровне.

Асимметричная многопроцессорная

В случае использования асимметричной многопроцессорности каждый процессор выполняет код операционной системы независимо от других процессоров. Каждая копия ОС может быть загружена в отдельный участок памяти, возможное также общее использование кода ОС разными процессорами с выделением отдельных участков памяти для данных. Этот подход был использован на ранних стадиях развития поддержки многопроцессорных архитектур в ОС. Приведем его недостатки.

• Все процессы пользователя некоторой копии ОС выполняются на том же процессоре, что и сама копия. Нет возможности организовать параллельное выполнение кода в рамках отдельного процесса, нельзя выравнивать нагрузку на отдельные процессоры и на память.

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

Симметричная многопроцессорная

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

Особенности SMP-систем приведены ниже.

• Все процессоры системы доступны из кода ОС. Планировщик ОС может организовать выполнение ее кода или кода потока пользователя на любом процессоре.

• Для всех процессоров доступны общие данные, при этом когерентность кэша поддерживается аппаратно.

• Потоки пользователя и потоки ядра могут выполняться параллельно на разных процессорах. Во время выполнения поток может мигрировать из процессора на процессор.

• Попытка повторного чтения одних и тех же данных процессором CPUA может дать другой результат в силу того, что эти данные были изменены процессором CPUB.

• В системе возможно выравнивание нагрузки между процессорами, для чего планировщик ОС может передавать новый поток для выполнения менее всего загруженному процессору.

• Добавление нового процессора в систему автоматически делает его доступным для выполнения кода ОС или процессов пользователя. При этом нагрузка на другие процессоры автоматически снижается.

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

Самым примитивным подходом для обеспечения синхронизации является большая блокировка ядра (big kernel lock). При этом каждый процессор перед выполнением любого кода ОС занимает глобальный м'ютекс. Этот подход неэффективен, поскольку в конкретный момент времени код ОС может быть выполнен только на одном процессоре.

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

Поддержка NUMA-архитектур

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

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