Компания IBM
Опубликован: 28.08.2008 | Доступ: свободный | Студентов: 471 / 68 | Оценка: 4.33 / 4.05 | Длительность: 31:19:00
Лекция 10:

Управление процессами

< Лекция 9 || Лекция 10: 123456 || Лекция 11 >
Мультипроцессирование

В предшествующем разделе описывались ситуации, подразумевающие наличие только одного процессора, и, следовательно, только одной исполняющейся задачи. На многопроцессорной же системе потенциально может быть несколько исполняющихся задач. Многопроцессорные системы поддерживаются механизмом диспетчеризации задач, большая часть которого присутствовала еще в оригинальной System/38, хотя никогда не использовалась на этой системе. Лишь в 1990 году мультипроцессирование было впервые использовано в AS/400. Оригинальная поддержка мультипроцессирования AS/400 до сих пор задействована не полностью, ее резервы предназначены для будущих расширений.

Симметричное мультипроцессирование

Ранее мы видели, что система симметричного мультипроцессирования (SMP) дает возможность ОС обрабатывать задачи на любом свободном процессоре или на всех процессорах сразу, при этом память остается общей для всех процессоров. Именно так устроена nканальная (nway) обработка на AS/400. Любой компонент ОС, включая диспетчер задач, может выполняться на любом или на всех процессорах системы.

Диспетчер задач в nканальной системе автоматически обеспечивает баланс нагрузки между процессорами, не требуя изменения программ, написанных для однопроцессорной архитектуры. Так как память для всех процессоров общая, диспетчер задач, независимо от процессора, на котором он выполняется, имеет доступ ко всем очередям, включая TDQ. Однако, диспетчер задач не ограничен тем процессором, на котором он выполняется, — он может вызвать переключение задач и на другом процессоре.

В многопроцессорной системе одновременно исполняется несколько задач — по одной на процессор. Упрощенно, следует лишь направить на выполнение верхние n TDE из TDQ. Естественно, эти n задач имеют наивысшую приоритетность среди всех готовых задач. Однако такой простой метод часто только кажется наилучшим.

Предположим, что у нас есть две задачи, А и В, исполняющиеся на процессорах 1 и 2 в двухпроцессорной системе. Предположим далее, что задача С, приоритет которой выше чем у А, но ниже чем у В, выходит из состояния ожидания. Ее TDE будет добавлен в очередь TDQ непосредственно перед TDE задачи А. Диспетчер задач выполнит переключение задач на процессоре 1, чтобы начать исполнение задачи С. Теперь допустим, что задача В на процессоре 2 либо завершилась, либо перешла в состояние ожидания. Приоритет задачи А — наивысший среди готовых задач, и ее следует направить на процессор 2. Но этот выбор может быть не лучшим.

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

Мы только что описали понятие сродства кэша (cache affinity). Говорят, что данная задача имеет сродство с некоторым процессором на основании содержимого его кэша. Диспетчеризация задач на многопроцессорной версии AS/400 использует комбинацию приоритета, сродства кэша и еще одной характеристики, под названием приемлемость (eligibility). Приемлемость используют, чтобы ограничить возможный набор процессоров для исполнения данной задачи. Приемлемость никогда не изменяется диспетчером задач. Если все процессоры, для которых приемлемо исполнение данной задачи, заняты задачами более высокого приоритета, то данная задача не направляется на выполнение.

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

Для диспетчеризации задачи на мультипроцессорной системе используются три поля TDE, а именно:

  1. Поле приемлемости, где содержится по одному биту на каждый процессор в системе. Если бит установлен, то задача приемлема для выполнения на соответствующем процессоре. Если установлены все биты, то задача приемлема для выполнения на всех процессорах.
  2. Поле активности, включающее по одному биту на каждый процессор в системе и указывающее процессор, на котором данная задача в настоящий момент активна. Может быть установлен максимум один бит, если задача выполняется. В противном случае, все биты сброшены.
  3. Поле сродства содержит по одному биту на каждый процессор в системе и указывает процессор, на котором данная задача исполнялась в последний раз.

Помимо только что описанной поддержки многопроцессорных систем, AS/400 может иметь множественные TDQ. Данный механизм был включен в оригинальную System/38, чтобы обеспечить диспетчеризацию нескольких очередей, но не использовался там для этой цели. Если число процессоров возрастет настолько, что одиночная TDQ станет тормозить работу системы, то диспетчеризацию можно будет осуществлять с помощью нескольких TDQ.

Современные nканальные процессоры используют модель SMP с разделяемой памятью, в которой все процессоры работают с одной и той же памятью. В "AS/400 в XXI веке" мы рассмотрим другие модели SMP, которые найдут применение в будущих системах AS/400. Все они поддерживаются существующей структурой задач.

Асимметричное мультипроцессирование

Давайте, хотя бы кратко, затронем системы асимметричного мультипроцессирования (ASMP). В системе ASMP части одной или даже разных ОС выполняются на выделенных процессорах. Структура задач AS/400 поддерживает и такую модель мультипроцессирования. Один из ранних проектов System/38 предусматривал несколько процессоров, каждый из которых выполнял часть ОС ниже MI. Идея состояла в том, чтобы выделить один процессор для СУБД, другой для управления памятью и т. д. В данном проекте ASMP использовалась та же структура задач для обмена сообщениями между процессорами и распределения работ. В точности такая модель мультипроцессирования никогда не использовалась в System/38. Однако в AS/400 была введена некая разновидность модели ASMP.

В "Система ввода-вывода" мы рассмотрим структуру вводавывода AS/400, которая существенно изменилась по сравнению с System/38. AS/400 использует множество процессоров для исполнения разных функций вводавывода. Большая система может иметь сотни таких процессоров. Мы увидим, что каждый из этих процессоров имеет собственную ОС. Хотя большинство из таких ОС разработаны специально для поддержки функций ввода-вывода, некоторые из них все же более универсальны. Такая архитектура позволяет другим ОС и написанным для них приложениям исполняться "под крышей" AS/400. Таким образом, к AS/400 возможно подключать множество таких машин-приложений в дополнение к основным процессорам.

Динамическое планирование приоритетов

В предыдущих разделах мы рассмотрели более понятную, но упрощенную модель диспетчеризации задач в AS/400. Со времен первой System/38 в структуру задач было внесено множество изменений для удовлетворения требований различных приложений и структур системы. Например, мы предполагали, что когданибудь системе понадобится динамически настраивать приоритет задачи во время исполнения. Предположим, что задача не получает достаточного для ее решения процессорного времени, или заблокировала некоторый системный ресурс, которого ожидает задача с большим приоритетом. Если бы система могла временно повышать и понижать приоритеты подобных задач, то можно было бы найти выход из только что описанных ситуаций. Такая возможность была добавлена в System/38 и ранние AS/400.

С появлением многопроцессорных конфигураций, и особенно в связи с нашим намерением использовать большее количество процессоров в конфигурациях SMP, было решено, что нужна более гибкая настройка приоритета задач. Группа исследователей в подразделении IBM Research в НьюЙорке работала над механизмом, который они назвали планировщик с оценкой задержки (delaycost scheduler). Специалисты из Рочестера подключились к этому проекту и вместе с IBM Research создали версию этого планировщика, которая теперь используется в SLIC на всех RISC-системах AS/400. Применяемые в планировщике алгоритмы, пожалуй, слишком сложны для этой книги. Но они вполне позволяют выполнять задачи вне порядка их приоритетов, если производительность системы при этом возрастает. В результате, загрузка RISC-процессоров становится более эффективной, особенно, в nканальных конфигурациях.

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

< Лекция 9 || Лекция 10: 123456 || Лекция 11 >