CC BY
13УДК 004.451.23:004.451.36
Оптимизация доступа к общей памяти для реализации стандарта PMIx1
А. В. Ефимов, А. Ю. Поляков, К. Е. Крамаренко, Б. В. Бочкарев
Получены результаты в области оптимизации стеков системного программного обеспечения распределенных вычислительных систем, основанных на интерфейсе управления процессами (Process Management Interface, PMI). Рассмотрены алгоритмы синхронизации доступа к общей памяти с преобладанием операций чтения, которые характерны для реализаций PMIx. Предложены схемы синхронизации N(mutex+signal) и N-MCS. Экспериментальные оценки показали снижение накладных расходов как операций чтения, так и записи.
Ключевые слова: распределенные вычислительные системы, интерфейс управления процессами, PMI, PMIx, общая память, синхронизация доступа.
1. Введение
В архитектурном плане распределенная вычислительная система (ВС) представляет собой композицию множества элементарных машин (ЭМ) и сети связей между ними [1]. Элементарная машина является основным структурным и функциональным элементом ВС. Структура ЭМ допускает варьирование от процессорного ядра до конфигураций вычислительных узлов, включающих универсальные и специализированные процессоры. Количество ЭМ в перспективных ВС может достигать десятков миллионов.
Основным назначением ВС является обработка вычислительных задач. Такие задачи содержат метаданные с описанием ресурсов ВС, необходимых для их решения, и могут состоять из одной и более параллельных программ (1111). Каждой ветви параллельной программы (экземпляр исполняемого двоичного файла) диспетчер ресурсов ВС сопоставляет ЭМ. Запуск задачи состоит из следующих этапов [2-5]: 1) развертывание среды исполнения (сервисных процессов); 2) запуск прикладных процессов, формирующих вычислительную задачу; 3) определение статического и динамического компонентов среды исполнения.
Библиотеки управления средой исполнения играют важную роль на всех этапах решения задачи и создаются на основе интерфейса управления процессами (Process Management Interface, PMI). PMI Exascale (PMIx) [6] - наиболее актуальная и стандартизированная версия PMI, разработанная для ВС экзафлопсного уровня производительности.
Интерфейс PMI абстрагирует прикладные процессы, формирующие задачу, от деталей реализации среды исполнения (СИ). Информация о СИ в PMI хранится в виде базы данных ключ-значение (Key-Value Database, KVDb), доступ к которой осуществляется через примитивы чтения (Get), записи (Put) и синхронизации (Commit, Fence). Эффективный доступ к KVDb является ключевым при реализации PMI, поэтому типичным является ее размещение в общей памяти вычислительного узла - это позволяет исключить системные вызовы при считывании информации о СИ [5].
1 Работа выполнена при финансовой поддержке РФФИ (проект № 20-07-00039) и Программы фундаментальных исследований СО РАН (ГЗ № 0306-2019-0019).
В данной работе выполнен анализ существующих схем синхронизации доступа к общей памяти (ОП) в реализациях стандарта РМ1х. На их основе предложено две новых схемы: М(тШ:ех+з1£па1) и ^-МСБ, характеризующиеся большей производительностью и низкими накладными расходами, что подтверждается экспериментальными исследованиями.
2. Синхронизация доступа к БД в стандарте РМ1х
Стек системного программного обеспечения (ПО) ВС, основанный на стандарте PMIx, включает в себя: а) эталонную реализацию PMIx (Open PMIx [7]); б) реализацию СИ (RunTime Environment, RTE); в) коммуникационную библиотеку; и г) среду параллельного программирования (MPI [8], OpenSHMEM). На рис. 1 показано расположение компонентов стека системного ПО на процессах распределенной операционной системы.
Рис. 1. Уровни системного программного обеспечения (ППр. - прикладной процесс, СПП - среда параллельного программирования, КБ - коммуникационная библиотека)
Прикладные процессы, формирующие задачу, взаимодействуют со средой исполнения через интерфейс PMI [3, 4]. Это гарантирует совместимость различных СИ с произвольными реализациями моделей и парадигм параллельного программирования. СИ может быть представлена как специализированной библиотекой [9, 10], так и диспетчером ресурсов ВС [11].
На каждом вычислительном узле, объединяющем несколько ЭМ общей оперативной памятью, создается агент СИ. Такой агент (рис. 1) включают в себя поток, выполняющий стандартные функции PMIx-сервера (реализован в библиотеке Open PMIx), и драйвер для взаимодействия с другими агентами, предоставляемый СИ. Прикладные процессы вычислительной задачи включают реализацию клиентской части PMIx, предоставляемую Open PMIx.
Агент СИ отвечает за поддержку базы данных PMI (KVDb) в актуальном состоянии. KVDb хранит как статическую, так и динамическую информацию о среде исполнения. Статическая информация включает в себя: уникальный целочисленный идентификатор (ранг) процесса ПП, общее количество прикладных процессов, список процессов, размещенных на одном узле, и т.д. Данная информация известна агенту СИ априори и не требует взаимодействия с агентами, расположенными на других узлах ВС.
К динамическим параметрам среды исполнения относятся специфичные для прикладных процессов данные, например, адресная информация, получаемая от коммуникационной подсистемы. Динамический компонент требует дополнительной синхронизации данных между агентами среды исполнения, расположенными на различных узлах ВС, что обуславливает накладные расходы на этапе инициализации вычислительной задачи.
Важными отличительными особенностями PMIk по сравнению с его предшественниками PMI-1 и PMI-2 являются [4]: а) сокращение динамического компонента информации о среде
исполнения за счет переноса значительной ее части, известной диспетчеру ресурсов, в статический компонент; б) режим обмена данными по требованию.
Внутриузловой доступ к KVDb является одним из узких мест существующих реализаций PMI [12]. Это, в основном, влияет на производительность примитивов Get и Put. Как сказано ранее, наиболее актуальным подходом к оптимизации доступа к KVDb является ее размещение в общей памяти. Такой способ обладает следующими преимуществами:
• масштабируемое потребление памяти: содержимое KVDb не дублируется на каждом прикладном процессе;
• параллелизм: общая память позволяет клиентам получать доступ к KVDb независимо (без участия сервера);
• низкие накладные расходы при доступе: операции осуществляются без выполнения системных вызовов, требующих переключения контекстов операционной системы.
Доступ к данным KVDb происходит с использованием операций глобальной и локальной (в рамках узла) барьерной синхронизации процессов, а также операций чтения или записи. В процессе выполнения синхронизационного примитива "Fence" (рис. 2) агент среды исполнения (поток «PMIx-сервер») блокирует общую память для записи (write lock) и размещает в ней содержимое KVDb. По завершению синхронизации прикладные процессы блокируют KVDb на чтение (read lock) и получают доступ к параметрам среды исполнения. Если требуемые параметры отсутствуют в локальной KVDb, то блокировка на чтение снимается и выполняется обращение к агенту СИ для запроса данных, размещенных на других узлах ВС. Поскольку прикладные процессы не модифицируют KVDb, они могут осуществлять одновременный доступ к ней при условии отсутствия операций записи со стороны агента СИ. Для обеспечения такого доступа используются примитивы синхронизации [13-15].
3. Обзор существующих алгоритмов синхронизации доступа к ОП
Важной особенностью PMIx является параллельное и интенсивное чтение данных KVDb, выполняемое PMIx-клиентами, в то время как только один процесс (PMIx-сервер) осуществляет доступ для записи и такая операция производится относительно редко. Рассмотрим подробнее схемы синхронизации, позволяющие обеспечить безопасный доступ к KVDb.
Первая схема синхронизации (рис. 3) основана на блокировке чтения-записи, предоставляемой стандартом POSIX [14]. В случае конкурентного доступа к KVDb каждый PMIx-клиент для чтения должен выполнить операцию захвата примитива синхронизации над одной и той же областью памяти. Это вызывает повышенную нагрузку на подсистему обеспечения когерентности процессорных кэшей узла ВС и приводит к высоким накладным расходам [5].
Рис. 3. Схема синхронизации на основе блокировки чтение-запись
Рис. 4. Схема синхронизации Ш-mutex
В работе [15] предложена реализация схемы синхронизации, обозначенная в данной работе Ш-тЩех (рис. 4), которая не приводит к перегрузке подсистемы обеспечения когерентности процессорных кэшей. Согласно Ш-тЩех для каждого РМ1х-клиента создается индивидуальный примитив синхронизации (тЩех), захват которого гарантирует атомарный доступ к КУЭЬ для чтения. Для записи требуется захват всех клиентских примитивов, что существенно ограничивает масштабируемость этой операции относительно количества РМ1х-клиентов.
Рис. 5. Схема синхронизации 2N-mutex
В настоящий момент в Open PMIx используется схема синхронизации 2N-mutex [5] (рис. 5), в соответствии с которой каждому PMIx-клиенту создаётся пара примитивов (mutex). Первый примитив (LSx) используется как сигнальный, а второй (LPx) - для доступа к ОП. Захватив примитив LPx, PMIx-клиент освобождает примитив LSx. При доступе для записи сначала осуществляется захват всех сигнальных примитивов (LSI - LSN), которые освобождаются PMIx-клиентами максимально быстро. На следующем шаге сервер захватывает основные примитивы (LPi - LPN), при этом блокировка сигнальных примитивов гарантирует, что новые попытки доступа для чтения не будут создавать дополнительных помех.
4. Оптимизация алгоритмов синхронизации доступа к ОП
В данной работе предложены две модификации алгоритма 2N-mutex, нацеленные на оптимизацию доступа к ОП в конкурентном режиме. Снижение накладных расходов предполагается за счет изменения способа сигнализации, реализованного в схеме 2N-mutex на основе примитива синхронизации LSx.
В схеме синхронизации N(mutex+signal) (рис. 6) сигнальный примитив LSx (mutex) заменен переменной VSx, что позволяет сократить количество атомарных операций, требуемых для захвата примитива синхронизации на чтение, и увеличить его производительность.
Рис. 6. Схема синхронизации N(mutex+signal)
Псевдокод алгоритмов захвата примитивов на запись и чтение в схеме синхронизации МтШ:ех+з1£па1) представлен на рис. 7. При доступе для записи (рис. 7а) выполняется установка всех сигнальных переменных (УБ1 - УБ^) в значение «1». После этого РМ1х-сервер последовательно дожидается освобождения и захватывает основные примитивы ЬРг.
При захвате примитива синхронизации на чтение (рис. 7 б) РМ1х-клиент сначала проверяет состояние соответствующей сигнальной переменной (УБх). До тех пор, пока она установлена, попытка захватить основной примитив синхронизации ЬРх не производится.
while(VS[x] noop(); lock(LP[x])
for i in 1 ... N: while (VS[x] = 1)
VS[i] = 1 for i in 1 . N: lock(LP[i])
а б
Рис. 7. Псевдо-код захвата примитивов в схеме синхронизации N(mutex+signal) (а) на запись; (б) на чтение (PMIx-клиентом с номером x)
Использование сигнальных примитивов LSx в схеме 2N-mutex и сигнальных переменных VSx в схеме N(mutex+signal) обусловлено тем, что стандарт POSIX Threads не требует соблюдения очередности доступа [16] и реализация примитива POSIX/mutex в библиотеке GNU C Library таким свойством не обладает.
Сократить время захвата примитивов синхронизации на запись возможно с применением примитивов, гарантирующих очередность доступа. В данной работе предложена схема синхронизации N-MCS, основанная на примитиве MCS [17]. Аналогично схеме 1N-mutex в N-MCS для каждого PMIx-клиента создаётся индивидуальный примитив MCS, расположенный в памяти, доступной как клиенту, так и серверу. Номер примитива PMIx-клиента соответствует его локальному рангу в рамках вычислительного узла. Как и в 1N-mutex, PMIx-серверу необходимо захватить все индивидуальные примитивы синхронизации, чтобы получить доступ для модификации KVDb.
Примитив синхронизации MCS имеет списочную структуру и гарантирует очередность доступа FIFO. Подробности реализации MCS представлены его автором в лекции [18]. Далее рассмотрим модификацию MCS, использованную в данной работе.
Структура примитива MCS (рис. 8) состоит из головного указателя (head) и двух списочных записей, соответствующих PMIx-клиенту (индекс record_idx = 1) и серверу (индекс rec-ord_idx = 2). В головном указателе размещается специальное значение "0", если примитив свободен, или индекс записи владельца примитива. Каждая запись состоит из двух полей: состояние блокировки (blocked) и индекс (next) претендента на примитив синхронизации или "0", если претендентов нет. В данной реализации MCS не предполагается наличие более одного претендента.
Head PMIx клиент PMIx сервер
Last Jdx blocked Nextidx blocked Nextjdx
(record Jdx -1) [0] [1]
Рис. 8. Структура примитива синхронизации MCS
Псевдокод захвата примитива синхронизации MCS (рис. 9) основан на атомарной операции fetch-and-store (atomic_swap). В головном указателе размещается индекс претендента, а в качестве результата возвращается индекс владельца примитива или индикатор "0" успешного захвата. Если у примитива уже есть владелец, то претендент переходит в фазу ожидания захвата. При этом в записи претендента в поле blocked устанавливается «1», а в записи владельца в поле next сохраняется индекс претендента. Далее у претендента запускается цикл опроса флага ожидания передачи права владения примитивом синхронизации.
MCS[x]->record[record_idx-1]->next = 0 prev_idx = atomic_swap(MCS[x]->head, record_idx) if(prev_idx = 0): return
MCS[x]->record[record_idx-1]->blocked = 1 MCS[x]->record[prev_idx-1]->next = record_idx while(MCS[x]->record[record_idx-1]->blocked): noop();
Рис. 9. Псевдокод захвата примитива MCS для схемы синхронизации N-MCS
Псевдокод освобождения примитива синхронизации MCS (рис. 10) основан на атомарной операции compare-and-swap (CAS). Если в головном указателе обнаружен индекс записи текущего владельца, то претендентов на владение нет и примитив синхронизации освобожден. При этом головной указатель уже установлен в специальное значение "0". Если операция CAS не выполнена, то поле next в записи текущего владельца содержит индекс следующего претендента. Тогда право владения передается путем установки поля blocked в записи претендента в значение "0".
if CAS(MCS[x]->head, record_idx, 0): return
while(MCS[x]->record[record_idx-1]->next = 0): noop();
next_idx = MCS[x]->record[record_idx-1]->next MCS[x]->record[next_idx-1]->blocked = 0 Рис. 10. Псевдокод освобождения примитива MCS для схемы синхронизации N-MCS
Варианты состояний примитива MCS приведены на рисунке 11: а) начальное состояние примитива; б) PMIx-клиент захватил примитив; в) PMIx-сервер встал в очередь на захват примитива, записал "1" в поле blocked, ожидает передачи права владения; г) PMIx-сервер захватил примитив; д) PMIx-клиент встал в очередь на захват примитива, записал "1" в поле blocked, ожидает передачи права владения.
Head PMIx клиент PMIx сервер
record idx
- процесс захватил замок
- процесс заблокирован
б)
Head PMIx клиент PMIx сервер Head PMIx клиент PMIx сервер
2 0 0 0 0
record idx ' 1 ' 2 ! record idx
г) д)
Рис. 11. Варианты состояний примитива синхронизации MCS
На рис. 11 также можно заметить, что поле head и его изменение посредством атомарных операций гарантирует очередность захвата примитива синхронизации. Для реализации POSIX/mutex в библиотеке GNU C Library характерно неограниченное количество попыток захвата примитива синхронизации и, следовательно, в среднем требуется более одной атомарной операции. В реализации MCS как для захвата, так и для освобождения примитива синхронизации требуется ровно одна атомарная операция.
Другой особенностью MCS, по сравнению с mutex, является процедура передачи права владения примитивом синхронизации, которая осуществляется владельцем и не требует дополнительных действий со стороны претендента. Таким образом, структура и логика MCS гарантирует очередность. Это позволяет обойтись без сигнального элемента, необходимого в схемах 2N-mutex и N(mutex+signal).
5. Методика проведения испытаний
Для оценки эффективности схем синхронизации доступа к ОП разработан микробенчмарк [19], в котором реализованы функции проверки корректности схем синхронизации, а также нагрузочные тесты. Тесты оценивают эффективность схем синхронизации в трех режимах: «только чтение», «только запись» и при конкурентном использовании. В последнем случае сервер осуществляет заданное количество операций записи (в данной работе - 100 итераций), перемежающихся с кратким ожиданием (10 мкс). До тех пор, пока сервер активен, клиенты производят непрерывный доступ для чтения, создавая помехи.
Псевдокод алгоритма тестирования эффективности схем синхронизации доступа к ОП при конкурентном использовании для чтения и записи представлен на рис. 12.
Эффективность схем синхронизации оценивается по следующим показателям: пропускная способность в режиме «только чтение» (количество захваченных примитивов в секунду -кзп/с), пропускная способность в режиме «только запись» (кзп/с), пропускная способность в конкурентном режиме (кзп/с), накладные расходы на конкурентный захват примитивов для записи (с). Замеры времени проводились с использованием функции РОБГХ clock_gettime.
global_cnt = 0 local_cnt = 0
for i in 1 ... 100: while (local_cnt < 100)
wlock(locks) rlock(locks[rank]);
global_cnt++ local_cnt = global_cnt;
unlock(locks) unlock(locks[rank]); usleep(10)
а) б)
Рис. 12. Листинг конкурентного захвата примитивов синхронизации: а) на запись (сервер); б) на чтение (клиент)
Эксперименты проводились для схемы синхронизации 2N-mutex, применяемой в промышленной реализации стандарта PMIx, а также для схем синхронизации N(mutex+signal) и 1N-MCS, предложенных в данной работе. В качестве экспериментальной базы использовались вычислительные NUMA-узлы с процессорами Intel (2 х Xeon E5-2680 v4) и AMD (2 х EPYC 7742) с числом ядер 28 и 128 соответственно. Запуск тестов осуществлялся через команду mpirun с директивой "--bind-to-core", гарантирующей фиксированное назначение каждому потоку уникального вычислительного ядра.
Измерение показателей эффективности схем синхронизации производилось 10 раз для каждого значения N с последующим вычислением среднего, среднеквадратического отклонения и относительной погрешности.
6. Результаты
Результаты экспериментов показали, что в режиме «только чтение» (рис. 13) предложенные схемы позволяют сократить накладные расходы примерно на 20 %. В режиме «только запись» (рис. 14), в зависимости от схемы и тестовой платформы, наблюдается двух-трёхкратное увеличение пропускной способности.
а) б)
Рис. 13. Пропускная способность схем синхронизации в режиме «только чтение»: а) узел 28 ядер (Intel); б) узел 128 ядер (AMD) - 2/V-mutex; - Mmutex+signal); -N-MCS
а) б)
Рис. 14. Пропускная способность схем синхронизации в режиме «только запись»: а) узел 28 ядер (Intel); б) узел 128 ядер (AMD)
Результаты оценки эффективности схем синхронизации при конкурентном захвате примитивов синхронизации на чтение и запись представлены на рис. 15 и 16 соответственно. Как видно на рис. 15, обе предложенные схемы синхронизации обеспечивают более высокую пропускную способность при доступе на чтение.
Рис. 15. Производительность конкурентного захвата примитивов синхронизации на чтение а) узел 28 ядер (Intel); б) узел 128 ядер (AMD)
2N-mutex;
■ N(mutex+signal);
N-MCS
а) б)
Рис. 16. Накладные расходы конкурентного захвата примитивов синхронизации на запись а) узел 28 ядер (Intel); б) узел 128 ядер (AMD)
Как и ожидалось (рис. 16), обе предложенные схемы снижают накладные расходы при конкурентном доступе на запись (время на выполнение функции lock()). В то время как N(mutex+signal) дает примерно 20-процентное преимущество, N-MCS обеспечивает улучшение в 3.75 раза для платформы на базе процессора Intel и в 6 раз для платформы на базе AMD. Данный эффект достигается в том числе за счет гарантий очередности, предоставляемых примитивом MCS, и фиксированного числа атомарных операций, требуемых для его реализации.
Относительная погрешность измерения производительности конкурентного захвата примитивов синхронизации на чтение в среднем составила 3 %. Относительная погрешность измерения накладных расходов конкурентного захвата примитивов синхронизации на запись в среднем составила 10 %.
Отклонение от тренда при N = 100-105 на узлах с процессорами AMD, вероятно, обусловлено микроархитектурными особенностями данного процессора. Наблюдаемые отклонения, однако, не влияют на соотношения между показателями производительности рассмотренных схем синхронизации.
7. Заключение
В работе предложены схемы синхронизации N(mutex+signal) и N-MCS, адаптированные для интенсивного доступа к общей памяти со значительным преобладанием операций чтения над операциями записи. Проведено экспериментальное исследование эффективности предложенных схем и схемы 2N-mutex, реализованной в настоящее время в библиотеке OpenPMIx.
Уменьшение числа атомарных операций в предложенных схемах синхронизации позволило увеличить пропускную способность примерно на 20 % в режиме «только чтение». В режиме «только запись» наблюдается двух-трехкратное увеличение пропускной способности.
Эффективность схем синхронизации при реализации конкурентного доступа к общей памяти на чтение оценивалась как среднее число блокировок в единицу времени, выполненное всеми клиентами за время испытания. Обе предложенные схемы позволяют увеличить пропускную способность приблизительно в два раза при относительной погрешность измерений, равной 3 %.
Эффективность схем синхронизации при реализации конкурентного доступа к общей памяти на запись оценивалась как накладные расходы времени на ожидание блокировки от момента инициализации операции до момента захвата всех клиентских примитивов. В данном режиме схема N(mutex+signal) позволяет снизить накладные расходы приблизительно на 20 %. В то же время N-MCS обеспечила преимущество в 3.75 раза для NUMA-узла на базе процессора Intel (28 ядер) и в 6 раз для NUMA-узла на базе AMD (128 ядер) при относительной погрешности измерений, равной 10 %.
Литература
1. Хорошевский В.Г. Архитектура вычислительных систем. М.: МГТУ им. Баумана, 2008. 520 с.
2. Yu W., Wu J., Panda D. K. Fast and Scalable Startup of MPI Programs in InfiniBand Clusters // Proc. 11th International Conference on High Performance Computing (HiPC), Bangalore, India, December 19-22, 2004. P. 440-449.
3. Balaji P., Buntinas D., Goodell D., at. al. PMI: A Scalable Parallel Processmanagement Interface for Extreme-scale Systems // Proc. 17th European MPI Users' Group Meeting Conference on Recent Advances in the Message Passing Interface (EuroMPI' 10). Springer-Verlag, Berlin, Heidelberg. P. 31-41.
4. Castain R. H., Solt D., Hursey J., Bouteiller A. PMIx: Process Management for Exascale Environments // Proc. 24th European MPI Users' Group Meeting (EuroMPI ' 17). ACM, New York, NY, USA, Article № 14, 10 p.
5. Polyakov A., Karasev B., Hursey J. et. al. A Performance Analysis and Optimization of PMIx-based HPC Software Stacks. EuroMPI '19: Proceedings of the 26th European MPI Users' Group Meeting. September 2019. Article № 9. P. 1-10.
6. PMIx Consortium. 2017-2020. Process Management Interface for Exascale (PMIx) Standard (version 3.1). [Электронный ресурс]. URL: https://github.com/pmix/pmix-stand-ard/releases/download/v3.1/pmix-standard-3.1.pdf (дата обращения: 10.04.2020).
7. Open PMIx master repository [Электронный ресурс]. URL: https ://github. com/open-pmix/openpmix (дата обращения: 10.04.2020).
8. Message Passing Interface Forum. 2015. MPI-3.1: Official document. [Электронный ресурс]. URL: http://www.mpi-forum.org/docs (дата обращения: 10.04.2020).
9. Argonne National Laboratory. 2014. Hydra Process Management Framework. [Электронный ресурс]. URL: https://wiki.mpich.org/mpich/index.php/ Hydra_Process_Management_Framework (дата обращения: 10.04.2020).
10. PMIx Reference RunTime Environment (PRRTE). [Электронный ресурс]. URL: https : //github . com/openpmix/prrte (дата обращения: 10.04.2020).
11. SchedMD, LLC. 2017. SLURM Workload Manager. [Электронный ресурс]. URL: https : //slurm. schedmd. com/ (дата обращения: 10.04.2020).
12. Chakraborty S., Subramoni H., Perkins J., Panda D. K. SHMEMPMI - Shared Memory Based PMI for Improved Performance and Scalability // Proc. 24th IEEE European MPI Users' Group Meeting (CCGrid). P. 60-69.
13. Calciu I., Dice D., Lev Y., Luchangco V. et. al. NUMA-aware reader-writer locks // Proc. 18th ACM SIGPLAN symposium on Principles and practice of parallel programming. ACM, New York, NY, USA, 2013. P. 157-166.
14. IEEE Standard for Information Technology-Portable Operating System Interface (POSIX(R)) Base Specifications, Issue 7. IEEE Std 1003.1-2017 (Revision of IEEE Std 1003.1-2008) (Jan 2018). P. 1-3951.
15. Hsieh W. C., Weihl W. E. Scalable Reader-Writer Locks for Parallel Systems // Proc. Sixth IEEE International Parallel Processing Symposium. 1992. P. 656-659.
16. IEEE Standard for Information Technology-Portable Operating System Interface (POSIX(R)) Base Specifications, Issue 7. IEEE Std 1003.1-2017 (Revision of IEEE Std 1003.1-2008) (Jan 2018). P. 1-3951. [Электронный ресурс]. URL: https://doi.org/10.1109/ ieeestd.2018 .8277153 (дата обращения: 01.09.2020).
17. Mellor-Crummey J., Scott M. Algorithms for scalable synchronization on shared-memory multiprocessors // ACM Trans. Comput. Syst. 1991. № 9. P. 21-65.
18. Mellor-Crummey J. Algorithms for Scalable Lock Synchronization on Shared-memory Multiprocessors. Department of Computer Science Rice University. Lecture 18. 17 March 2009. P. 1-49.
[Электронный ресурс]. URL: https://cs.anu.edu.au/courses/comp8320/lec-tures/aux/comp422-Lecture18-HWLocks . pdf (дата обращения: 10.04.2020). 19. Микробенчмарк. [Электронный ресурс]. URL: https : //bitly. su/Wtxe0Z (дата обращения: 01.09.2020).
Ефимов Александр Владимирович
к.т.н., доцент СибГУТИ (630102, Новосибирск, ул. Кирова, 86), ведущий инженер-элек-троник ИФП СО РАН (630090, Новосибирск, пр-кт. Ак. Лаврентьева, 13), тел. (383) 269-82-93, e-mail: alexandr. v. efimov@gmail. com.
Поляков Артём Юрьевич
старший архитектор программного обеспечения NVIDIA Corporation (Santa Clara, California, USA), e-mail: artemp@nvidia.com.
Крамаренко Константин Евгеньевич
ст. преподаватель СибГУТИ, инженер-программист ИФП СО РАН, тел. (383) 269-82-86, e-mail: kostya. kram@gmail. com.
Бочкарев Борис Вячеславович
ассистент СибГУТИ, тел. (383) 269-82-86, e-mail: boris-bochkaryov@yandex. ru.
Shared memory access optimization for PMIx standard implementation A. V. Efimov, А. Y. Polyakov, K. E. Kramarenko, B. V. Bochkarev
The results in the field of optimization of system software stacks for distributed computing systems based on the process management Interface (PMI) are obtained. Algorithms for synchronizing access to shared memory with a predominance of reading operations, which are typical for PMIx implementations, are considered. The locking schemes Mmutex+signal) and N-MCS are proposed. Experimental estimates have shown a reduction in the overhead of both read and write operations.
Keywords: distributed computing systems, resource management, process management interface, PMI, PMIx, shared memory.
