Параллельные вычисления в ИММ УрО РАН
 
 

Развитие и адаптация системного программного обеспечения МВС-100

А.С.Игумнов, А.В.Коновалов, В.В.Самофалов, С.В.Шарф

Работа проводилась при финансовой поддержке Российского фонда фундаментальных исследований (грант No 97-01-00672).

Рассматривается набор аппаратно-программных, а также административных решений и методов, позволивших резко повысить надёжность и эффективность работы МВС-100. Описанные решения активно используются в ИММ УрО РАН.

ОС GNU/Linux c МВС-100

Описанная в [3] организация МВС-100 предполагает, что для связи МВС-100 с внешним миром используется ОС Helios – реализованная на транспьютерах имитация ОС Unix. Применение этой операционной системы для терминального доступа в сочетании с традиционной серверной ОС (например NetWare либо WindowsNT), предоставляющей доступ к файлам, позволяет достаточно комфортно использовать МВС-100 в рамках небольшой, тесно связанной группы исследователей. Однако невысокая надежность работы ОС Helios при повышении сетевой нагрузки и слабые возможности по авторизации, бюджетированию и ограничению доступа требуют подыскать ей замену.

В ИММ УрО РАН для взаимодействия МВС-100 с внешним миром применена ОС GNU/Linux – свободно распространяемый клон Unix'а. ОС Linux содержит в стандартной комплектации все необходимые компоненты для администрирования системы, удаленного доступа и разработки вспомогательного программного обеспечения, такого как системы пакетной обработки задач и сбора статистики. Кроме того, использование ОС Linux позволило легко интегрировать МВС-100 в локальную сеть, построенную с использованием файл-сервера Novell NetWare.

ОС Helios может по-прежнему использоваться для одновременного запуска многих задач, однако единственная её функция в новой системе – выбор задач из очереди и их запуск под управлением пакетного режима. Такая специализация делает ненужным TCP/IP на Helios'е – главный источник проблем с безопасностью.

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

В состав программного обеспечения, свободно распространяемого в рамках проекта GNU, входит дисассемблер поддерживающий формат COFF-файлов (т.е. объектных и исполняемых модулей), в который компилируются программы на МВС-100. В этот дисассемблер была добавлена поддержка для команд процессора i860, в результате чего получена пилотная версия дисассемблера для МВС-100, которая использовалась при изучении прерываний i860. Версия работает под управлением ОС GNU/Linux 2.0.

Симметричный пакетный режим

Эксплуатирующаяся в ИММ система запуска задач – пакетный режим – постоянно совершенствуется, следуя за развитием аппаратной базы МВС-100. На сегодняшний день пакетный режим представляет собой совокупность организационных, аппаратных и программных средств, обеспечивающих коллективное использование МВС-100. Так как при массовых запросах к общему ресурсу очередь возникает почти неизбежно, то формирование и обслуживание очереди задач – это основные программные составляющие системы. Наша реализация этих компонент обладает рядом особенностей, что обусловлено как спецификой аппаратной части имеющегося в ИММ экземпляра МВС-100, так и наличием достаточного количества разноплановых задач. Ниже речь пойдет о следующих наиболее интересных характеристиках пакетного режима: гибкости при задании вариантов запуска задач; переключении режимов планирования в соответствии с расписанием для конкретных дней недели, дат, времени суток или групп пользователей; согласованном обслуживании очереди задач одновременно многими менеджерами.

Для начала отметим, что на МВС-100, в силу особенностей аппаратного и базового системного обеспечения (ОС Router прежде всего), задача при счете полностью монопольно занимает одно или несколько вычислительных полей – групп процессоров, связанных по управлению. В таких условиях вполне оправданно планирование на базе предварительного заказа ресурсов. Организованное внешним по отношению к ОС Router способом оно не требует существенных переделок последней, а в полной мере использует развитую поддержку многозадачности операционных систем host-машин.

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

Такая организация позволяет оперативно удовлетворять потребности пользователей, которые возникают при освоении ими МВС-100. Например, чтобы определить ускорение счета, достигаемое для конкретных задач на более мощных процессорах, потребовался запуск задач на полях со старыми процессорами. Специальные ключи предусмотрены также для программ на языке Фортран GNS [4] и для отладки вносимых в ОС Router изменений, так как здесь требуется запуск задачи с btl-файлами пользователя, а не со стандартными, как во всех остальных случаях.

При планировании учитываются и установленные на текущий момент конкретные значения параметров планирования. Задание различных режимов планирования для разных дней недели или групп пользователей обеспечивает более гибкое регулирование потока задач с учетом принципа "социальной справедливости" [5] и важности решаемых задач.

Как уже отмечалось, в ИММ МВС-100 функционирует под управлением двух host-машин. На каждой из них постоянно работает менеджер очереди задач, осуществляющий запуск задач только с такими стартовыми вычислительными полями, сигналы управления на которые идут с данной host-машины. Если запускаемой задаче требуются дополнительные вычислительные поля, связанные по управлению с другой host-машиной, то туда посылается запрос, который обрабатывается отдельной программой. Эта же программа обслуживает инициированные пользователями запросы на принудительное досрочное завершение их задач. При этом поддерживается иллюзия слияния двух host-машин в одну, так как все запросы посылаются прозрачным для пользователя образом.

Разделение системы на части по функциональному признаку позволяет размещать ее на машинах в зависимости от потребностей. Например, может быть изменено число менеджеров очереди задач или обработчиков запросов, а программы формирования очереди могут выполняться на ЭВМ пользователя. Синхронизация при функционировании различных частей осуществляется посредством операций над общими файлами Novell NetWare. Основную роль здесь играет операция переименования файла, так как она неделима и в отличие от операции уничтожения позволяет просто отслеживать и исправлять остающиеся после сбоя захваты. Простота реализации окупает временн\'ые издержки, тем более, что в случае обслуживания очереди задач они оказываются незначительными по сравнению с временем загрузки пользовательских программ в МВС-100.

В настоящее время в ИММ через пакетный режим в обычный день проходит порядка 100 задач 20 пользователей, которые загружают вычислитель примерно на 20 %. (За 100 % принимается круглосуточная загрузка всех 64 процессоров.) После перехода на симметричную схему даже в конце года, при возрастании загрузки до 35 %, не возникало особых проблем, хотя выявились некоторые резервы. В дальнейшем предполагается развивать прежде всего интерфейсную часть, а также совершенствовать алгоритмы планирования.

Развитие механизмов взаимодействия

Прерывания на i860

В настоящее время всё взаимодействие программы пользователя, выполняющейся на i860, с внешним миром происходит по запрос-ответной технике. Достоинство такого подхода – крайне низкие накладные расходы. Накопленный опыт позволяет утверждать, что распараллеливание по типу фермы вполне соответствует этому подходу. Однако, если прикладная задача не выразима в терминах фермы и подобных простых схем, сложность её реализации резко возрастает. По нашему мнению, основное препятствие в реализации более развитых схем взаимодействия на МВС-100 – асимметрия в связке i860-транспьютер, т.е. невозможность инициировать никакие действия с транспьютера на i860, не разрушая необратимо пользовательскую программу.

Применение прерываний – общепринятой техники реализации асинхронного взаимодействия – позволяет эффективно реализовать в системе развитые механизмы взаимодействия процессов. Эти механизмы должны быть ориентированы на расширение круга решаемых прикладных задач за счёт упрощения организации сложных протоколов.

Ещё одной областью применения прерываний может стать отладка на базе использования отладочного регистра deb и механизма защиты страниц i860.

В настоящее время есть возможность вызвать прерывание i860 с транспьютера, выполнить в обработчике требуемые действия и продолжить программу пользователя. Проведено тестирование корректности восстановления на доступных прикладных программах. Корректность работы сохраняется. Существенных временн\'ых потерь из-за затрат на переключение контекстов не зафиксировано.

Все работы проводились с процессорами i860/XR.

Учёт топологии транспьютерной сети

С апреля 1997 г. работающая в ИММ УрО РАН МВС-100 включает в себя 64 процессора, разбитых на 5 вычислительных полей. Использование стандартной ОС Router (см. [1]) в сочетании с пакетным режимом [5] для подобной конфигурации МВС-100 приводит к тому, что генерация загружаемых btl-модулей для транспьютерной сети занимает 2,5 ч на машине DX/2-66 (20 МБайт памяти), а самих btl-модулей генерируется более 100 МБайт. Причины этого понятны – поле для запуска задачи выбирается диспетчером задач автоматически, поэтому для каждой возможной конфигурации транспьютерной сети нужен свой btl-модуль. Суммарный размер модулей и, особенно, время их генерации создают существенные проблемы при администрировании больших конфигураций МВС-100.

Эти трудности были разрешены введением в ОС Router аппарата логических номеров, с использованием которых и обмениваются между собой программы пользователя. Введение логических номеров позволяет создавать новый btl-модуль лишь при добавлении нового вычислительного поля. Это уменьшает время генерации системы до 15 мин и резко сокращает общий размер btl-модулей. Для генерации необходимых пакетному режиму btl-модулей разработан набор утилит, которые на входе принимают вывод программ ispy|mcheck, размеченный информацией о том, к какому полю относится данный процессор.

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

Для управления размещения процессов по процессорам предлагается расширение формата run-файлов повторителями, комментариями, указанием, какой процесс на какой физический процессор загружать, и желательным расстоянием от процессора с указанным номером. Рассмотрим пример.

# мастер
master.860 | 10
3:sl.860 +1
2:sl1.860 +2

Комментарии начинаются с # и продолжаются до конца строки. Процесс {\tt master.860} получает логический номер 0 и попадает на 10-й физический процессор, три процесса sl.860 (логические номера 1-3) желательно разместить поближе к master.860, а sl1.860 (логические номера 4, 5) можно и подальше.

Управляя размещением по физическим процессорам, можно без каких-либо изменений параллельной программы ускорять обмен между процессами, так как все обмены организованы по логическим номерам. Отсутствием интеллектуальных затрат оправдывается даже небольшое (10 %) ускорение, достигаемое, например, в задаче об отыскании стабильного моста.

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

В ноябре 1997 г. описываемые в настоящем пункте дополнения к ОС Router переданы в эксплуатацию в ИММ УрО РАН.

ОС Router: модификация стандартной версии

Проверка длины сообщений

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

Проверка длины была добавлена в ОС Router следующим образом. Как известно (см. [2]), каждый пакет, на которые разбивается посылка, снабжается заголовком. В стандартом случае этот заголовок имеет размер 3 слова. Расширение заголовка пакета до 4 слов позволяет передавать длину сообщения в пакете, сообщающем о готовности принять. Подобное лобовое решение несколько замедляет обмены, однако даже на специально написанных ("плохих") задачах это замедление достигало примерно 5 %. На реальных задачах сколько-нибудь существенного замедления не зарегистрировано.

На уровне конечного пользователя несовпадение длин выглядит так. Если длины при чтении-записи не совпадают, то с процессора-писателя выдается сообщение ``Error! Proc NN write MM bytes to proc PP insted of ZZ.'', после чего выполнение процесса-писателя будет насильственно прекращено.

Ускорение проверки и ожидания завершения обмена

Измерения показывают, что вызов функции проверки завершения приёма t_read в стандартной ОС Router занимает слишком много времени. Такое поведение легко объяснимо реализацией: t_read обращается к транспьютеру.

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

Тестовые примеры, основанные на интенсивном использовании t_read, демонстрируют ускорение порядка 7 % при переходе к взаимодействии через общую память.

Исправление ошибки при работе с кэшем

Согласно [6], кэш i860/XR устроен так. Когда процессор читает данные, в строку кэша попадает целый блок памяти размером 32 байта, который содержит указанное при обращении слово. В случае последующей модификации данных информация об их изменении хранится для полустроки кэша, т.е. 16 байт. Если теперь попытаться очистить строку кэша, то в основную память будут переписаны все данные полустроки кэша, в том числе и неизменявшиеся.

Предположим теперь, что транспьютер пишет по адресу с данными в кэше. Тогда при модификации соседних данных (из той же полустроки) выталкивание кэша затрёт записанное транспьютером. Существует тест, подтверждающий наличие проблемы для Router'а, запускаемого на TTM110 и ВМ232.

Для исправления ошибки в Router'е были сделаны следующие изменения: во время приёма начало и конец сообщения копируются не только в указанную пользователем область памяти, но и в специальные системные буфера, расположенные в памяти i860. Данные из внутренних буферов переписываются в пользовательский буфер самим процессором i860 при проверке завершения приёма, что исключает неприятности с кэшем ценой незначительного замедления (порядка нескольких процентов).

Заключение

Опыт эксплуатации МВС-100 в ИММ наглядно демонстрирует, что при коллективном использовании требования надежности, авторизации доступа и удобства работы выходят на первый план. Интеграция множества программных компонент, в том числе написанных для различных платформ (Linux, Windows 95, Novell Netware, DOS, Helios, Router), позволила суммировать преимущества каждой из них, поднять надежность и сохранить привычную для пользователя среду разработки. Кроме того, построение системы по модульному принципу из компонент, специализированных для одной функции, облегчает адаптацию программ к непрерывно возрастающим в ходе освоения новой техники потребностям пользователей. Авторы выражают признательность Л.Д.Попову, С.В.Поповой и М.Ю.Храмцову (ИПМ РАН) за полезные дискуссии и помощь в отладке.

Литература

  1. Лацис А.O., Луцкий А.Е. Численное решение задач газовой динамики на многопроцессорной ВС // Тез. докл. IV конф. ``Транспьютерные системы и их применение''. Домодедово, 1994.
  2. Лацис А.O. Операционная среда ROUTER для транспьютерных систем. Документация по МВС-100.
  3. Лацис А.О. Разработка ОС коллективного использования для многопроцессорной супер-ЭВМ МВС-100 // Тез. докл. V конф. ``Транспьютерные системы и их применение''. Домодедово, 1995.
  4. Поздняков Л.А., Храмцов М.Ю. Мобильная система программирования Фортран GNS для многопроцессорных систем с распределённой памятью // Вопр. атом. науки и техн. Сер. Матем. моделирование физ. процессов. 1996. Вып. 4. С. 38-42.
  5. Шарф С.В. Планирование прохождения задач на МВС-100 // Тез. докл. VI конф. ``Транспьютерные системы и их применение''. Домодедово, 1996.
  6. N.Margulis I860 Microprocessor Architecture INTEL. Osborne: McGraw-Hill, U.S.A.