CC BY
21
NO. 5 (53) 2014
journal of applied informatics
Е. А. Юлюгин, студент Московского физико-технического института, ЗАО «Интел А/О»,
yulyugin@gmail.com
Г. С. Речистов, канд. техн. наук, ЗАО «Интел А/О», Москва,
grigory.rechistov@phystech.edu
Моделирование инструкций поддержки транзакционной памяти в современных центральных процессорах
Аппаратная поддержка транзакционной памяти становится доступной в новейших процессорах. В статье описывается реализация набора инструкций RTM в функциональном симуляторе Wind River® Simics. Цель работы — обеспечение корректного исполнения новых инструкций и сохранение высокой скорости работы симулятора, которую может продемонстрировать Simics.
Ключевые слова: Simics, RTM, TSX, моделирование, транзакционная память.
введение
В настоящее время аппаратная поддержка транзакционной памяти [1] (англ. Hardware transactional memory, далее HTM) становится доступной в коммерческих продуктах ведущих компаний — производителей процессоров. Фирма IBM предлагает режим HTM в суперкомпьютерах BlueGene/Q [2] и серверах zEnterprise EC12 [3]. Набор инструкций «Transactional Synchronization Extensions» (Intel® TSX) присутствует в микропроцессорах компании Intel с кодовым именем Haswell [4]. Тем не менее использование программных моделей для исследования приложений, использующих HTM, остается актуальным, так как симуляция предоставляет возможности по отладке, нередко отсутствующие в аппаратуре.
Поддержка транзакционной памяти в функциональном симуляторе не является тривиальной, так как моделирование кэшей, необходимое для их корректной работы, обычно опускается в целях максимального ускорения моделей процессоров. Включение же кэшей в модель может сделать множество использованных оптимизаций бес-
полезными. Необходимо обеспечить, чтобы при работе кода, не использующего новые инструкции, скорость симуляции оставалась высокой.
Кроме того, публичная документация на Intel® TSX [5, глава 8] не дает представления о некоторых внутренних деталях аппаратной реализации, важных при построении модели. Эта неопределенность приводит к необходимости создания гибкого решения, позволяющего конфигурировать нижележащие параметры модели, чтобы иметь возможность адаптировать модель под различные варианты аппаратных реализаций.
С учетом «хрупкости» семантики инструкций RTM (т. е. отсутствия в спецификации каких-либо гарантий, что транзакция сможет завершиться успехом) простейшая реализация инструкций должна просто отменять каждую из транзакций в самом ее начале. Однако такое решение не является полезным для изучения влияния нового механизма на производительность приложений. В данной работе была создана реализация, позволяющая моделируемым процессорам успешно завершать транзакции. Кроме того, важнейшим требованием
№ 5 (53) 2014
к реализации TSX было сохранение высокой скорости при симуляции программ, никак не использующих новые инструкции.
Обзор литературы
В поддержке транзакционной памяти в своей продукции заинтересованы как многие производители процессоров, так и различные исслледовательские группы из зарубежных университетов. Данных о публикациях или иных материалах, касающихся отечественных разработок в данной области, не имеется.
Компания IBM первой представила на рынке систему в процессоре систем BlueGene/Q. AMD объявила о разработке расширения Advanced Synchronization Facility [6], представляющего собой еще один вариант HTM для архитектуры IA-32, однако продукция, реализующая спецификации, выпущена не была. Компания Sun разработала процессор с кодовым именем ROCK [7], однако данный проект был закрыт.
Существует также множество программных реализаций идей транзакционной памяти. Обычно они не требуют специальной поддержки посредством аппаратуры. Однако изучение существующих решений показывает их крайне низкую производительность, которая перевешивает основные достоинства модели TM.
Множество симуляторов, основанных на Simics, реализуют TM вместе с GEMS [8] — специализированным симулятором кэшей. Y. Liu и другие [9] предлагает неофициальное расширение архитектуры SPARC, нацеленное на механизм транзакций. Симулятор Sun ROCK, поддерживающий HTM, описан в [7]. Указанная работа, как и данная, основывается на Simics/GEMS и исследует архитектуру SPARC.
В отличие от авторов рассмотренных работ, мы сконцентрировались на исследовании официально анонсированных технологий и архитектуры IA-32. Подобное расширение AMD ASF для AMD64 реализовано и изучено в потактовом симуляторе PTLSim [10].
Существует еще один симулятор Intel® SDE [11], который поддерживает Intel TSX. Однако с его помощью невозможно измерить RTM операции на системном программном обеспечении вроде Linux, так как он является симулятором режима приложений.
Обзор Wind River Simics
Wind River® Simics [12] является быстрым функциональным симулятором, используемым для полноплатформенного моделирования вычислительных систем, состоящих из многих процессоров, ОЗУ, периферийных устройств, таких как жесткие диски, сетевые и графические карты и т. д. Simics достаточно точно симулирует такие системы, чтобы быть в состоянии загружать немодифи-цированные операционные системы, такие как GNU/Linux, Microsoft Windows, VxWorks и др. Следует отметить, что Simics не является потактово точным, т. е. в обычном режиме не может давать детальные предсказания о производительности систем.
Для архитектуры Intel IA-32 данный продукт предоставляет модели для большинства расширений набора инструкций, включая векторные команды SSE, AVX и AVX2, технологию виртуализации Intel® VTx, аппаратную поддержку верификации исполняемого кода Intel® TXT и др. Модели процессоров в Simics являются одновременно быстрыми и легко расширяемыми благодаря тому, что каждая из них может быть обеспечена тремя симуляционными режимами, динамически переключаемыми прозрачно для пользователя.
1. Интерпретатор — самый гибкий, но и самый медленный режим.
2. Двоичная трансляция гостевых инструкций в хозяйские. Этот режим быстрее интерпретации, но в то же время требует больше усилий для добавления новых инструкций.
3. Режим VMP использует аппаратную виртуализацию технологии Intel® VTx [13] для того, чтобы исполнять гостевой IA-32 код напрямую, возвращаясь к интерпрета-
No. 5 (53) 2014
тору или двоичной трансляции в тех случаях, когда это невозможно. Данный режим самый быстрый, однако вход в него осуществляется только для исполнения достаточно длинных непрерывающихся интервалов, поддерживаемых системой инструкций.
обзор техники транзакционной памяти и существующих реализаций
Расширение Intel® RTM архитектуры IA-32 состоит из четырех новых инструкций для входа, выхода, отмены и проверки статуса транзакций [5].
• XBEGIN label определяет вход в транзакцию. При этом логический процессор сохраняет состояние своих регистров в точке сохранения и переходит в так называемый спекулятивный режим. Дальнейшие доступы в память задерживаются в промежуточном хранилище до тех пор, пока не произойдет исполнение инструкции XEND или некоторое так называемое разрушительное событие не отменит транзакцию целиком. В последнем случае состояние процессора восстанавливается из точки сохранения, а регистр-указатель инструкций RIP переводится на адрес, на который указывает label. При этом никаких чтений или записей в память не происходит.
• XEND означает успешное завершение ранее начатой транзакции. При этом все задержанные доступы на запись в память атомарно проводятся, а хранившаяся точка сохранения регистров очищается как далее ненужная.
• XABORT condition принудительно отменяет текущую транзакцию. Значения для всех регистров процессора восстанавливаются из точки сохранения, кроме EAX, в который записывают код condition.
• XTEST — устанавливает или сбрасывает флаг CF процессора в зависимости от того, находится он в спекулятивном режиме или нет.
Документация позволяет выполнять вложенные до некоторой глубины транзакции, но при этом она требует, чтобы все внутрен-
ние пары XBEGIN и XEND не создавали новые точки сохранения.
Введение расширений транзакционной памяти подразумевает, что семантика всех инструкций, работающих с памятью, а также инструкций, влияющих на состояние процессора, не сохраняемое в точках сохранения, должна быть изменена, чтобы поддерживать новый спекулятивный режим исполнения.
Некоторые инструкции не могут быть успешно выполнены внутри транзакции и должны всегда приводить к ее отмене. Согласно спецификации это CPUID, PAUSE и XABORT.
Кроме того, любая другая инструкция, эффекты выполнения которой невозможно отменить, также должна вызывать немедленную отмену транзакции, так как иначе невозможно будет гарантировать восстановление исходного состояния процессора в случае более позднего отката транзакции. К таким инструкциям относятся следующие:
• математические команды сопроцессора x87 для чисел с плавающей запятой;
• инструкции ввода-вывода IN, OUT;
• инструкции, оперирующие сегментными, отладочными, виртуализационными, системным и/или модель-специфичными регистрами, системной частью регистра EFLAGS, например: LDS, дальний CALL, VMENTER, CLI и т. п.;
• переходы между режимами с разными привилегиями: SYSENTER, SYSCALL и т. д.;
• сохранение расширенного состояния: XSAVE/XRSTR;
• кроме того, все прерывания и исключения также вызывают откат транзакции.
Реализация
Наиболее часто используемыми устройствами в Simics являются ram и rom, которые представляют непрерывный массив данных, доступных для чтения и записи или только для чтения. Они используются для моделирования многочисленных RAM и EEPROM устройств, присутствующих в современных системах.
Наиболее гибкий класс устройств Simics называется translator. Он может обеспечивать произвольную логику над входящими транзакциями, например для изменения адреса. Такое устройство, названное snare, было создано для реализации кэша трансляций, который содержит состояние спекулятивной памяти до того, как оно будет зафиксировано. Каждый симулируемый поток процессора имеет собственный экземпляр такого типа, подключенный к себе. Также все snare устройства соединены между собой для определения возможных конфликтов. Главная идея заключается в динамической модификации карты пространств памяти в зависимости от входа или выхода из спекулятивного режима.
Пусть core [x] [y] будет ядром под номером x и потоком под номером y симулируемого многоядерного процессора, который инициирует операции доступа в память. Возможны три различные ситуации в системе с RTM.
1. Ни один из потоков не находится в транзакции в данный момент (рис. 1). В такой ситуации устройство snare полностью отключено, и транзакции проходят без изменений. Это гарантирует сохранение скорости при исполнении старых инструкций.
2. core [x] [y] находится внутри спекулятивного региона, а другие могут как быть, так и не быть в соответствующих спекулятивных регионах (рис. 2). snare активен и находится между закрытым пространством памяти текущего потока mem [x] [y] и общим пространством phys_mem. Он перенаправляет входящие транзакции в новый ram объект tx_store [x] [y], используемый как кэш, наполняемый данными в случае кэш-промахов. Вторая функция snare заключается в наблюдении за другими share-объектами для определения конфликтов памяти и извещения core [x] [y].
3. core [x] [y] не использует TM, но хотя бы один удаленный поток находится в спекулятивном регионе (рис. 3). Существует необходимость определения конфликтов памяти, именно поэтому snare [x] [y] и подключен.
№ 5 (53) 2014
Рис. 1. Ни один поток не находится в спекулятивном регионе, все транзакции проходят без изменений
Однако проходящие через него транзакции не перенаправляются в кэш.
Описанное решение отделяет логику HTM от ядра процессора, подвергающегося минимальным изменениям, которые включают декодирование новых инструкций, сохранение/ восстановление состояния контрольных точек и (наиболее трудоемкое и утомительное) определение некоторых классов инструкций как отменяющих транзакцию. Большая часть логики RTM была сделана в устройстве snare и заняла приблизительно 2000 строк кода. Мы переиспользовали исходный код стандартной кэш-модели Simics g-cache; в оригинале он предоставляет настраиваемый кэш с протоколом когерентности MESI. Он был существенно модифицирован для наших целей: из модели была удалена поддержка вычисления задержек операций, добавлены новые интерфейсы для взаимодействия с мо-
Рис. 2. Текущий поток находится в спекулятивном регионе, добавлено новое snare устройство
No. 5 (53) 2014
ram: ram periph. devices
1
phys_memory: memory-space
.1
snare[x][y]: tm-snare
T
snares
mem[x][y]: memory-space
I
core[x][y]: Haswell
Рис. 3. Текущий поток не использует
транзакционную память, но хотя бы один удаленный поток — использует
делью ядра процессора, протокол когерентности был упрощен на порядок для простого определения конфликтов.
измерения
Эксперименты проводились на рабочей станции с одним центральным процессором Intel i7-2600 3.40 ГГц и 8 Гбайт ОЗУ, использовалась 64-битная ОС SUSE Linux Enterprise Server 10.
Исследуемые приложения
В данной работе исследовались следующие приложения и сценарии:
1. Загрузка ядра Linux версии 3.5.0 (64 бит), модифицированного для того, чтобы пытаться избежать всех критических регионов с помощью транзакций, как описано в [14]. В случае, когда транзакция откатывает несколько раз подряд, алгоритм переходит к использованию классических замков.
2. Набор тестов производительности STAMP [15] версии 0.9.10. Данные приложения были написаны для исследования различных реализаций транзакционной памяти.
Набор инструкций RTM был добавлен в продукт Wind River® Simics версии 4.6 (сборка 4082) для процессора с кодовым именем Intel Haswell. Частота ядра была выставлена в 2000 МГц, число моделируемых ядер варьировалось от 2 до 32 в экспериментах с ядром Linux и от 1 до 16 в опытах со STAMP. Пара-
метры используемых кэшей соответствовали публичной информации для кэшей первого уровня для Haswell, т. е. 32 килобайта, ассоциативность 8, размер линий 32 байта.
Результаты измерений скорости симуляции
Для загрузки ядра Linux изучалось значение скорости, измеряемое в MIPS (миллионы гостевых инструкций за одну хозяйскую секунду), сообщаемое средствами мониторинга производительности, встроенными в Simics. Среднее значение MIPS приводится для интервала от возникновения приглашения загрузчика GRUB до момента монтирования корневой файловой системы.
Для оценки замедления симуляции, вызванного необходимостью выполнения RTM-инструкций, сравнивались три сценария работы: 1) инструкции RTM включены и видимы гостевой ОС и приложениям, а режим VMP активен вне спекулятивных регионов; 2) поддержка RTM выключена, VMP включен постоянно; 3) RTM включен, но VMP принудительно выключен и не используется. На рис. 4 показано, что при включении RTM симуляция замедляется примерно в три раза. Тем не менее для чисел ядер, меньших 32, включенный режим VMP даже только для регионов без транзакций дает некоторое ускорение по сравнению с ситуацией, когда VMP принудительно отключен.
В качестве предмета изучения эффективности симуляции RTM на пользовательских приложениях были проанализированы тесты производительности из набора STAMP.
Входные параметры для каждого теста брались из файла README, входящего в поставку пакета (табл. 1). Из восьми программ пакета удалось скомпилировать все, но успешно запущено только семь — тест labyrinth заканчивался ошибкой вскоре после старта, поэтому данные для него не приводятся.
На рис. 5 приведены данные по скорости симуляции отдельных тестов из состава STAMP. Как и ожидалось, в целом симуляция пользовательских приложений происходила быстрее, чем моделирование системного кода ядра ОС, потому что при этом
20
№ 5 (53) 2014
« 80
Количество моделируемых процессоров
Рис. 4. Зависимость скорости симуляции загрузки ядра Linux от числа моделируемых ядер и режима работы
требовалось симулировать гораздо меньшее число сложных привилегированных инструкций, и большие фрагменты программ могли быть исполнены в режиме VMP.
В симуляторе была реализована функциональность для записи частот возникновения различных связанных с RTM событий в группе счетчиков, доступных через интерфейс командной строки Simics. На рис. 6 приводится информация об относительной частоте различных причин завершения транзакций, собранная для сценария загрузки Linux и исполнения тестов STAMP. Обозначения различных классов событий: committed — успешно завершенные записью результатов в память; capacity — отмененные из-за переполнения транзакцион-ного КЭШа; conflict — два или более потока обращались к одному и тому же региону памяти внутри транзакций; exception — ис-
ключение, случившееся внутри спекулятивного региона; instruction — инструкция, запрещенная внутри транзакции, прервала ее ход; interrupt — внешнее прерывание возникло в момент нахождения процессора внутри спекулятивного региона.
По результатам экспериментов были сделаны следующие выводы.
• Сценарий загрузки ядра Linux продемонстрировал самый высокий процент отмен транзакций по причине попытки исполнения запрещенной внутри транзакции инструкции. Это обстоятельство подчеркивает тот факт, что не все критические секции ядра ОС могут быть эффективно преобразованы в транзакции RTM.
• Поведение отдельных тестов STAMP в целом совпадало с описанным в [9]. Например, наименьшие доли отмен транзакций наблюдались для kmeans и ssca2.
Таблица 1
Использованные параметры для запуска отдельных тестов STAMP
Имя теста Параметры запуска
Bayes -v32 -r1024 -n2 -p20 -s0 -i2 -e2 -t 16
genome -g256 -s16 -n16384 -t 16
intruder -a10 -l4 -n2038 -s1 -t 16
kmeans -m15 -n15 -t0.05 -i inputs/random -n2048-d16-c16.txt -p 16
labyrinth N/A — failed to run
ssca2 -s13 -i1.0 -u1.0 -l3 -p3 -t 16
vacation -n2 -q90 -u98 -r16384 -t4096 -c 16
yada -a20 -i inputs/633.2 -t 16
No. 5 (53) 2014
Рис. 5. Скорости исполнения тестов STAMP
- ! ! 1 I _ committed v f rollback: capacity kvvnm rollback: conflict rollback: exception i rollback: instruction rollback: interrupt
ЧА ч ? >0 X X X % 4 % %
Рис. 6. Зависимость скорости симуляции загрузки ядра Linux от числа моделируемых ядер и режима работы
Определение №Пег1Р
Построенный инструмент позволяет провести профилирование с целью обнаружения мест в коде, вызывающих наибольшее количество откатов транзакций (КШеМР). На рис.7 приведен пример собранного
профиля для теста bayes, исполняемого на 4 симулируемых потоках. Из данного графика видно, что инструкция с шестнадцати-теричным адресом 0x4037b6 вызывает наибольшее количество откатов транзакций. Поэтому приложение требует дополнительного анализа в этой точке.
№ 5 (53) 2014
60
СП
,1..
11
■ ■___■ - ■ - ■ I ■ -1 ■ I ■ I ■
> % +г ^ 's- > V 's- *г
%%%%%%%%
Рис. 7. Вычисление KillerIP
0
Заключение
В данной статье описаны модификации Wind River Simics, выполненные для поддержки расширения набора команд Intel® Restricted Transactional Memory. Изначальная цель — минимизация влияния модификаций на работу модели — была достигнута переносом кэша транзакций в отдельное устройство. Затем проведена проверка того, что созданная программная модель корректно симулирует загрузку двух операционных систем, а также набора пользовательских приложений под их управлением. Также было показано, что скорость моделирования была достаточной для использования данной модели в разработке. Результаты данной работы были включены в пакет Wind River® Simics Haswell. Модификации STAMP для поддержки RTM были опубликованы на Github (https://github.com/ grigory-rechistov/stamp-rtm).
Следует заметить, что на данный момент RTM-инструкции только интерпретируются в Simics, JIT для них не включен. Это негативно сказывается на скорости симуляции. Есть намерение включить JIT-режим — это не должно потребовать радикальных изменений в ядре Simics, так как большая часть кода у JIT и интерпретатора общая. Также планируется провести обширную верифи-
кацию реализации в аспекте корректности работы более широкого спектра пользовательских приложений, библиотек и операционных систем.
В конце следует заметить, что вторая часть Intel TSX документации описывает расширение HLE (Hardware Lock Elision), в котором вводится альтернативный, обратно совместимый, метод для игнорирования замков с помощью двух префиксов инструкций IA-32. Планируется также использовать подход, описанный в данной работе, для моделирования HLE.
Список литературы
References
1. Herlihy M., Moss J. E. B. Transactional memory: architectural support for lock-free data structures, in: Proceedings of the 20th annual international symposium on computer architecture, ISCA '93, ACM, N. Y., USA, 1993. Р. 289-300. doi: 10.1 145/165123.165164. URL: http://doi.acm. org/10.1145/165123.165164.
2. Merritt R. IBM plants transactional memory in CPU, EE Times. URL: http://www.eetimes.com/electron-ics-news/4218914/IBM-plants-transactional-mem-ory-in-CPU.
3. IBM unveils zEnterprise EC12, a highly secure system for cloud computing and enterprise da-
No. 5 (53) 2014
journal of appued informatics
ta (August 2012). URL: http://www-03.ibm.com/ press/us/en/pressrelease/38653.wss.
4. Rajwar R., Dixon M. Intel transactional synchronization extensions (2012). URL: http://intel.com/go/ idfsessions.
5. Intel Corporation, Intel® Architecture Instruction Set Extensions Programming Reference (July 2012). URL: http://software.intel.com/file/41417.
6. Chung J., Diestelhorst S, Pohlack M, Hohmuth M, Christie D., Grossman D. ASF: AMD64 extension for lock-free data structures and transactional memory (2010).
7. Moir M., Moore K., Nussbaum D. The adaptive transactional memory test platform: a tool for experimenting with transactional code for ROCK (poster), in: Proceedings of the twentieth annual symposium on Parallelism in algorithms and architectures, SPAA '08, ACM, New York, NY, USA, 2008, pp. 362-362. doi: 10.1145/1378533.1378595. URL: http://doi.acm.org/10.1145/1378533.1378595.
8. Martin M. M. K,. Sorin D. J., Beckmann B. M, Marty M. R, Xu M, Alameldeen A. R, Moore K. E, Hill M. D., Wood D. A. Multifacet's general execution-driven multiprocessor simulator (GEMS) toolset, SIGARCH Comput. Archit. News 33 (4) (2005) 92-99. doi: 10.1145/1105734.1105747. URL: http:// doi.acm.org/10.1145/1105734.1105747.
9. Liu Y, Su Y, Zhang C, Wu M, Zhang X, Li H, Qian D. Efficient transaction nesting in hardware transactional memory, in: Proceedings of the 23rd international conference on Architecture of Com-
puting Systems, ARCS'10, Springer-Verlag, Berlin, Heidelberg, 2010, pp. 138-149. doi: 10.1007/978-3-642-11950-7_13. URL: http://dx.doi.org/10.100 7/978-3-642-11950-7_13.
10. Diestelhorst S, Pohlack M, Hohmuth M, Christie D., Chung J.-W., Yen L. Implementing AMD's Advanced Synchronization Facility in an out-of-order x86 core, 5th ACMSIGPLAN Workshop on Transactional Computing.
11. Intel Software Development Emulator. URL: http:// software.intel.com/en-us/articles/intel-software-de-velopment-emulator.
12. Magnusson Peter S., Christensson Magnus, Es-kilson Jesper, Forsgren Daniel, Hallberg Gustav, Högberg Johan, Larsson Fredrik, Moestedt Andreas, Werner Bengt. A Full System Simulation Platform, Computer 35 (2002) 50-58. doi: 10.1 109/2.982916. URL: http://portal.acm.org/ citation.cfm?id=619072.621909.
13. Leung F., Neiger G., Rodgers D., Santoni A., Uh-lig R. Intel® Virtualization Technology, Intel Technology Journal 10. doi: 10.1535/itj. 1003.01. URL: http://www.intel.com/technology/itj/2006/v10i3.
14. Kleen A. Adding lock elision to Linux (August 2012). URL: http://www.linuxplumbersconf.org/2012/wp-con-tent/uploads/2012/08/Adding-lock-elision-to-Linux.pdf.
15. Minh C. C., Chung J., Kozyrakis C., Olukotun K. STAMP: Stanford transactional applications for multi-processing, In IISWC '08: Proceedings of The IEEE International Symposium on Workload Characterization.
E. Yulyugin, Student, Moscow Institute of Physics and Technology, Intel Corporation, yulyugin@gmail.com G. Rechistov, Phd in Technique, Intel Corporation, Moscow, grigory.rechistov@phystech.edu
simulation of instruction set extension for transactional memory of modern central processors
Hardware transactional memory is finally becoming available in products from major vendors. Intel announced that a set of transactional synchronization extensions (TSX) is available in it new processor microarchitecture, codenamed Haswell. The benefits of software simulation of this technology will remain significant even after processors that support new instructions become available on the market. The reason for this is that a simulation often provides more flexibility during debugging and architecture exploration. Transactional memory support in functional simulator is not trivial because it requires explicit cache simulation, which may dramatically affect performance. It was necessary to create a flexible reconfigurable model, as public documentation for TSX omits implementation details. In this paper we describe our implementation of Intel® restricted transactional memory (RTM) instructions, which are a part of the Intel® TSX, in the full system functional simulator Wind River® Simics. Our goal was to ensure correct execution of these new instructions while maintaining high simulation speed that Simics is able to demonstrate. Keywords: Simics, TSX, RTM, simulation, transactional memory.
