Software & Systems

Проблема построения эффективных вычислительных систем, решающих разнообразные задачи – от научных до военных, упирается в доставку данных до вычислительных компонент: будь то центральный процессор, специализированная интегральная схема или графический ускоритель. В то время как на аппаратном уровне идет бурное развитие различных сетевых идеологий, с программной точки зрения самым распространенным средством передачи данных для многопроцессорных комплексов является интерфейс передачи сообщений (MPI) [1].

Разработанная в НИИСИ РАН микросхема 1890ВМ6Я, являющаяся микросхемой общего назначения, имеет в своем составе, помимо всего прочего, центральный процессор, мощный математический сопроцессор и контроллер RapidIO [2]. Коммутатор RapidIO 1890КП3, также разработанный в НИИСИ РАН, позволяет объединить эти микросхемы в сеть RapidIO и сформировать высокопроизводительный многопроцессорный вычислительный комплекс. Далее в данной статье представлена реализация MPI для вычислительного комплекса на базе микросхем семейства 1890ВМ6Я с возможностью исполнения операций приема/передачи данных по RapidIO без копирования (zero-copy/data offload).

При решении задачи запуска MPI-приложений на вычислительном комплексе возникает один из главных вопросов – рабочее окружение, состоящее из таких компонентов, как ядро ОС и набор библиотек. В качестве ядра ОС было выбрано ядро Linux, так как оно в связке с библиотеками MPI показало свою эффективность в распределенных вычислениях [3–5], а в качестве библиотеки MPI – MPICH как одна из широко используемых реализаций MPI [6].

Архитектура библиотеки MPICH

В процессе своего развития библиотека MPICH пришла к стройной многоуровневой архитектуре [7, 8] (см. рис. 1).

В верхней части библиотеки находится совместимый со стандартом MPI версии 2.2 интерфейс, предоставляемый прикладным программам. Ниже по уровню располагается логическое устройство, реализующее абстрактный интерфейс устройства (Abstract Device Interface version 3 – ADI3 Interface). Портирование MPICH для определенной коммуникационной среды может заключаться в реализации такого ADI3-устройства (например, на рисунке 1 это CH3 Device). Данный подход позволяет наилучшим образом наложить интерфейс библиотеки на конкретное оборудование, однако процесс разработки и сопровождения полного ADI3-устройства может быть весьма трудоемким из-за своей сложности и постоянного развития верхнего уровня (поддержка более новых версий MPI может повлечь за собой введение новых или изменение старых функций).

Другой подход заключается в разработке устройства более низкого уровня, взаимодействующего с имеющимся в библиотеке MPICH ADI3 устройством (CH3 Device) по интерфейсу CH3I. Устройства такого уровня называются каналами. Естественно, добавление нового уровня абстракции немного снижает производительность, но разработка и сопровождение такого канала требуют значительно меньше трудовых затрат. Однако практика показала, что разработчики вместо реализации каналов для конкретного оборудования перерабатывали само CH3-устройство. Стало ясно, что интерфейс CH3I не удовлетворял потребностям современных на то время технологий. Отсюда возникла необходимость в создании еще одного слоя абстракции, позволяющего стабилизировать CH3I-интерфейс.

Таким образом, был представлен канал Nemesis для CH3-устройства [9]. Ключевыми особенностями Nemesis являются масштабируемость, высокая производительность для внутриузловых и межузловых обменов, а также поддержка разнородных сетевых каналов передачи. Главные компоненты Nemesis – высокооптимизированная система сообщений для внутриузловых обменов и средства для реализации сетевых модулей (Network Modules – netmod), которые позволили реализовать модули, взаимодействующие с контроллерами Myrinet, Infiniband и Ethernet. Базовой функцией сетевого модуля является передача служебных сообщений и массивов данных через коммуникационную среду.

Рассмотрим процесс разработки стека RapidIO от драйвера контроллера RapidIO до реализации сетевого модуля для Nemesis и обоснуем принятые решения.

Драйвер контроллера RapidIO

Контроллер RapidIO в 1890ВМ6Я реализует следующие механизмы передачи данных стандарта RapidIO: IO-транзакции [10], сообщения и так называемые дверные звонки (doorbell) [11]. Дверные звонки могут передать максимум 2 байта данных за одну транзакцию. Они предназначены, например, для оповещения о случившемся прерывании, а не для передачи массивов данных.

Использование IO-транзакций (в частности, NREAD и NWRITE – чтение и запись памяти удаленного узла) возможно путем выполнения процессорных инструкций чтения/записи специальной транслируемой области памяти, которая указывает на память удаленного узла. Каждая такая инструкция может либо загрузить, либо записать данные размером до 8 байт. Если учесть размер служебного заголовка для транзакции (6 байт + 6 бит), то он получается почти равным размеру передаваемых данных, что дает весьма низкую эффективность использования такого рода транзакций в данной реализации контроллера RapidIO.

Сообщения позволяют передавать до 4 Кб данных. Каждое сообщение состоит из сегментов, количество которых может достигать 16, а размер каждого из них не превышает 256 байт. По спецификации RapidIO гарантируются доставка сообщений до места назначения и сохранение порядка передачи с помощью полей «номер письма» (номер сообщения) и «номер сегмента» в заголовке. Оно также имеет дополнительное поле (подкраску) – номер почтового ящика, который служит для разделения входящих потоков сообщений. Таким образом, сообщения являются наиболее приемлемым способом передачи данных ввиду своей высокой эффективности и необходимости наименьшего числа транзакций для данных размером более 8 байт. Далее по тексту под буфером будет пониматься область памяти, разбитая на сообщения либо на отправку, либо на прием.

Контроллер сообщений RapidIO микросхемы 1890ВМ6Я имеет ряд особенностей.

·       8 выделенных очередей, программируемых на прием сообщений от заданного узла с заданным номером почтового ящика. С помощью механизма выделенных очередей становится возможным прием данных напрямую в буфер назначения без промежуточных копирований данных (zero-copy). Такой прием назовем приемом ожидаемого пакета.

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

·       Проблема сегментов разной длины. По спецификации RapidIO сообщение состоит максимум из 16 сегментов, размер которых одинаков (размер сегмента не больше 256 байт), кроме последнего сегмента. Отправитель посылает сегменты один за другим, одновременно ожидая статуса доставки каждого сегмента от узла получателя. При возникновении заторов в коммуникационной среде любой сегмент может быть отклонен получателем, что приводит к повторной отправке недоставленного сегмента. Отсюда возможна следующая ситуация, когда все сегменты, кроме последнего, были отклонены получателем. Тогда этот успешно полученный последний сегмент расположится в памяти по адресу адрес_буфера + 256 байт * (количество_сегментов – 1). Если же размер всех предыдущих сегментов меньше 256 байт, можно с уверенностью сказать, что произошла порча памяти у получателя в момент записи последнего сегмента, если, конечно, буфер был рассчитан только на прием действительного размера сообщения. В качестве простого решения этой проблемы введем ограничение выравненности размера буферов отправки и приема на 256 байт.

·       Физический адрес буфера должен быть выравнен на 8 байт. Из предыдущего требования вытекает требование выравненности адреса буфера, лежащего в транслируемой виртуальной памяти, на 256 байт. Но логика работы контроллера RapidIO микросхемы 1890ВМ6Я при приеме в выделенную очередь заключается в том, что количество отправленных сообщений и размер каждого из них должны точно совпадать с числом и размерами запрограммированных сообщений на стороне получателя. Поэтому для упрощения увеличим требо- вание выравненности для адреса такого буфера до 4Кб.

Для передачи сообщения на уровне прикладной программы, использующей MPI, на первом узле необходимо вызвать функцию передачи MPI_Send, а на другом – функцию приема MPI_Recv. Для MPI_Send задаются параметры: ID получателя, TAG сообщения («подкраска» сообщения), адрес буфера и его размер. Для MPI_Recv должны быть заданы соответствующие параметры, которые либо точно совпадают с параметрами отправки ID и TAG, либо представляют собой особые значения MPI_ANY_SOURCE для ID или MPI_ANY_TAG для TAG, которые пропускают любые соответствующие значения. Такой парный подход вызовов MPI_Send/MPI_Recv для приема/передачи данных позволяет воспользоваться выделенными очередями контроллера RapidIO микросхемы 1890ВМ6Я для приема и последующей отправки в них данных «без копирования». После успешного открытия выделенной очереди информация о номере почтового ящика должна быть передана узлу-отправителю. Для передачи такого рода контрольной информации зарезервируем нулевой почтовый ящик, а остальные номера предоставим выделенным очередям.

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

Управляющий уровень драйвера контроллера RapidIO

Так как число выделенных очередей и почтовых ящиков ограничено, а порядок вызовов MPI функций-запросов на прием, которые могут побудить открытие выделенной очереди, строго говоря, не детерминирован, необходимо осуществлять динамическое присвоение номера почтовому ящику и открытие выделенной очереди для одного определенного узла. Эта работа отнесена на отдельный управляющий уровень. При недостатке свободных очередей или почтовых ящиков запросы на выделенную очередь откладываются до тех пор, пока не станет доступным недостающая часть.

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

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

Граница между маленькими и большими данными сильно зависит от самой аппаратуры, поэтому устанавливается эмпирическим путем. Если по результатам измерения эта граница расположи- лась за пределами 4 Кб, то данные маленького размера, превышающие 4 Кб, будут разбиты на не- сколько сообщений RapidIO драйвером контроллера. Для последующей обработки таких данных на узле-получателе необходимо их все собрать в единый пакет, что возможно благодаря введенному заголовку.

Таким образом, в управляющем уровне можно выделить следующие интерфейсные функции: отправка данных в общую очередь узла-назначения (маленький размер данных или контрольная информация вместе с заголовком о типе данных и их размере – протокол управляющего уровня); прием неожиданных пакетов, собранных из нескольких сообщений; регистрация буфера (выделение при необходимости связующего буфера или получение физических адресов из транслируемых виртуальных); запрос на открытие выделенной очереди для приема в зарегистрированный буфер; отправка зарегистрированного буфера в заданный почтовый ящик.

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

Высшие уровни и тестирование

В числе пользователей канала RapidIO – виртуальное устройство Ethernet (см. рис. 2). Стек Ethernet является базовой необходимостью, так как с его помощью работают многие полезные протоколы, например telnet и ssh. Другим пользователем является уровень MX (см. рис. 2), который реализует интерфейс передачи сообщений по значениям «ключ-маска», в достаточно хорошей степени точ- ности соответствующий интерфейсу передачи сообщений MPI, описанному выше.

Интерфейс Myrinet eXpress [12], использующийся в сетевом модуле mx библиотеки MPICH, также соответствует интерфейсу передачи сообщений MPI. Этот сетевой модуль был взят как справочник при реализации библиотеки пользовательского уровня MXlib, которая реализует интерфейс Myrinet eXpress для работы с ядерным уровнем MX. С этой библиотекой стала возможной работа библиотеки MPICH поверх канала RapidIO через использование сетевого модуля mx.

В качестве аппаратуры для измерения произ- водительности MPI были взяты 4 ПЛИС с ядром микросхемы семейства 1890ВМ6Я, соединенные каналами RapidIO, пиковая пропускная способность которого составляет 192 МБ/с. На одном, двух и четырех узлах были запущены тесты NAS Parallel Benchmarks (NPB) [13] класса А, которые достигли 80 %-ной эффективности масштабирования при увеличении количества узлов. Также была измерена производительность между двумя узлами тестами OSU Micro-Benchmarks [14], результаты которых представлены в таблице.

Результаты измерения производительности стека RapidIO при работе связки MX + MPICH

Measurement results for RapidIO stack performance with operating MX + MPICH

На основании изложенного можно сделать следующие выводы. Реализованный в данной статье стек RapidIO для MPI показал свою работоспособность на различных программах – тесты NAS Parallel Benchmarks, OSU Micro-Benchmarks, тесты MPICH. На тесте передачи сообщений OSU удалось достичь скорости передачи в 84 % от пиковой. Благодаря расширению области тестирования путем запуска разнообразных MPI-программ были выявлены и устранены ранее неизвестные ошибки в логике работы контроллера RapidIO.

При использовании готовых библиотек добиться максимальной производительности можно только на аппаратуре, функциональные возможности которой соответствуют идеологии обмена данными, заложенной в самой библиотеке. В целом контроллер RapidIO микросхемы 1890ВМ6Я лишь частично соответствует стандарту MPI, а соответственно, и его библиотечным реализациям. Так, например, для передачи большого массива данных необходимо произвести «ручное» программирование каждого сообщения в соответствии с таблицей физических адресов, в то время как такая тривиальная работа может быть реализована в железе. Необходимость разрешения конфликтов выравненности буферов на обоих узлах также влечет дополнительные накладные расходы на процессор, в худшем случае прибегая к копированию данных.

Другим примером является введенный в стандарт MPI версии 2 интерфейс RMA (Remote Memory Access), который позволяет совершать операции чтения и записи памяти любого размера удаленного узла. Микросхема 1890ВМ6Я предоставляет весьма скудный механизм такого удаленного доступа к памяти – IO-транзакции типа NREAD и NWRITE с полезной нагрузкой до 8 байт, хотя по стандарту RapidIO полезная нагрузка может составлять 256 байт.

Недостатком является и получившаяся сильная перегруженность стека драйверов, что делает отправку и прием данных слишком дорогой операцией. По грубым оценкам, получилось больше 20 тысяч процессорных инструкций для передачи всего лишь одного байта данных. Это означает, что при частоте процессора в 1 ГГц передать один байт получится не меньше, чем через несколько десятков микросекунд. Конечно, с ростом передаваемого объема данных сама подготовка к передаче будет становиться исчезающе малой, но факт задержки, тем не менее, останется. Поэтому необходима дальнейшая работа по ее уменьшению.

Автор выражает благодарность Лазутину Юрию Михайловичу (ФНЦ НИИСИ РАН) за помощь в подготовке данной статьи.

Литература

1.     Message Passing Interface Forum. MPI: A message-passing interface standard, version 3.0, 2012. URL: http://www.mpi- forum.org/docs/mpi-3.0/mpi30-report.pdf (дата обращения: 25.07.2015).

2.     Бобков С.Г., Еремин А.А., Кондратьева Н.В., Сер- дин О.В. Разработка высоконадежных многопроцессорных модулей на базе высокоскоростных каналов RapidIO // Програм- мные продукты и системы. 2013. № 4. С. 49–55.

3.     Yang C., Xiao L., Lu Yu., Liao X. MilkyWay-2 super­computer: system and application. Front. Comput. Sci., 2014, no. 8 (3), pp. 345–356.

4.     Graham R.L., Gutierrez S.K., Hjelm N.T., Venkata M.G. Performance Evaluation of Open MPI on Cray XE/XK Systems. High-Performance Interconnects (HOTI), 2012 IEEE 20th Annual Symposium, 22–24 Aug. 2012, pp. 40–47.

5.     Sato M., Tsuji M. / Performance Evaluation of OpenMP and MPI Hybrid Programs on a Large Scale Multi-core Multi-socket Cluster, T2K Open Supercomputer. Parallel Processing Workshops, 2009. ICPPW '09. Intern. Conf., 22–25 Sept. 2009, pp. 206–213.

6.     MPICH is a high performance and widely portable implementation of the Message Passing Interface (MPI) standard. URL: https://www.mpich.org/ (дата обращения: 25.07.2015).

7.     Архитектура библиотеки MPICH первой версии. URL: http://www.mcs.anl.gov/research/projects/mpi/mpich1-old/papers/ mpicharticle/node21.html#Node21 (дата обращения: 25.07.2015).

8.     Pritchard H., Gorodetsky I., Buntinas D. A uGNI-Based MPICH2 Nemesis Network Module for Cray XE Computer Systems. EuroMPI'11 Proceedings of the 18th European MPI Users' Group conference on Recent advances in the message passing interface, pp. 110–119.

9.     Buntinas D., Mercier G., and Gropp W. Design and Evaluation of Nemesis, a Scalable, Low-Latency, Message-Passing Communication Subsystem. In CCGRID’06, 2006, pp. 521–530.

10.  RapidIO Interconnect Specification. Part 1: Input/Output Logical Specification. Revision 2.2. RapidIO Trade Association, 2011. URL: http://www.rapidio.org/specs/current/Ra­pidIO_ Rev_ 2.2_Specification.zip (дата обращения: 25.07.2015).

11.  RapidIO Interconnect Specification. Part 2: Messsage Pass- ing Logical Specification. Revision 2.2. RapidIO Trade Association, 2011. URL: http://www.rapidio.org/specs/current/RapidIO_Rev_ 2.2_Specification.zip (дата обращения: 25.07.2015).

12.  Myricom, Inc. Myrinet Express (MX): A High Perfor­mance, Low-Level, Message-Passing Interface for Myrinet. URL: http://www.myri.com/scs/MX/doc/mx.pdf (дата обращения: 25.07.2015).

13.  NAS Parallel Benchmarks: небольшой набор программ, созданных для помощи в оценке производительности параллельных суперкомпьютеров. URL: http://www.nas.nasa.gov/pub­lications/npb.html (дата обращения: 25.07.2015).

14.  OSU Micro-Benchmarks: тесты производительности вычислительных узлов с использованием MPI. URL: http://mvapi­ch.cse.ohio-state.edu/benchmarks/ (дата обращения: 25.07.2015).