Источники недетерминированности в симуляциях gem5 ARM

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

Содержание

• Внутреннее генерирование случайных чисел
• Моделирование сетевых устройств и зависимости от времени
• Управление памятью и зависимости адресов
• Проблемы внешнего времени и синхронизации
• Специфические для DPDK проблемы интеграции
• Состояния гонки и вариации планирования
• Ограничения процесса контрольных точек и восстановления

Внутреннее генерирование случайных чисел

Фреймворк DES gem5 разработан для обеспечения детерминированности через фиксированные种子 генерации случайных чисел, однако некоторые компоненты могут по-прежнему вводить тонкие вариации. Хотя базовый механизм моделирования использует детерминированные种子, некоторые подсистемы могут иметь собственные механизмы случайной генерации, которые не полностью синхронизированы в циклах контрольных точек и восстановления.

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

В вашей полной системе моделирования ARM модель процессора O3 может обращаться к генераторам случайных чисел в слегка разных точках потока инструкций между запусками, что влияет на точное время принятия решений по обработке сетевых пакетов.

Моделирование сетевых устройств и зависимости от времени

Моделирование сетевого адаптера (NIC) в gem5 является особенно распространенным источником недетерминированности. Сетевые устройства часто включают операции, чувствительные ко времени, где точная последовательность событий может влиять на количество передаваемых пакетов.

Ваше конкретное наблюдение недетерминированных TX-пакетов при детерминированных RXPackets указывает на зависящее от времени поведение в передающем пути. Как отмечается в обсуждении на gem5-users о недетерминированных результатах в режиме FS, этот точный шаблон - детерминированные счетчики приема, но переменные счетчики передачи - наблюдался в настройках gem5-dpdk.

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

Управление памятью и зависимости адресов

Хотя вы отключили ASLR с помощью norandmaps, внутреннее управление памятью gem5 все еще может вводить тонкую недетерминированность. Шаблоны выделения памяти, шаблоны доступа к кэш-строкам и сопоставления виртуальных и физических адресов могут различаться между запусками даже при идентичных контрольных точках.

Документация dist-gem5 подчеркивает, что gem5 избегает “зависимости от адресов хоста” для детерминированности, но внутреннее управление памятью, специфичное для моделирования, все еще может создавать временные вариации.

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

Проблемы внешнего времени и синхронизации

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

Хотя вы не используете KVM, определенные системные вызовы в вашей рабочей нагрузке DPDK все еще могут обращаться к информации о времени, которая различается между запусками. Даже если приложение не содержит “случайной логики”, как отмечено в вашей настройке, системные вызовы могут вводить внешние зависимости.

Статья о моделировании полной системы GPU упоминает, что моделирование становится “более детерминированным” при использовании кода процессора на стороне хоста с ускорением KVM, что указывает на то, что внешние временные взаимодействия являются признанной проблемой для детерминированности.

Специфические для DPDK проблемы интеграции

Интеграция DPDK с gem5 вводит несколько потенциальных источников недетерминированности. Как описано в статьи об обеспечении обхода ядра в сети на gem5, это включает расширение модели оборудования NIC и драйвера устройства в gem5 для поддержки драйверов устройств в пространстве пользователя.

Исследование по сетевому взаимодействию в пространстве пользователя в gem5 отмечает, что DPDK обращается к регистру Command с использованием 8-битных операций памяти, что может создавать зависимости от времени. Точная ширина байта и время этих обращений к регистрам могут влиять на то, как сетевое устройство обрабатывает пакеты.

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

Состояния гонки и вариации планирования

Даже в детерминированных моделях состояния гонки между параллельными компонентами могут привести к недетерминированному поведению. Модель процессора ARM O3 создает сложные временные зависимости, где точная последовательность выполнения инструкций и операций памяти может различаться между запусками.

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

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

Ограничения процесса контрольных точек и восстановления

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

Обсуждение о детерминированности моделирования предполагает, что использование KVM для ускорения до ROI и затем создание контрольной точки может улучшить детерминированность, хотя вы специально избегаете KVM в своей настройке.

Процесс восстановления контрольных точек может не идеально захватывать точные временные отношения между событиями, особенно в сложных многокомпонентных системах, таких как ваша полная система моделирования ARM с сетью DPDK.

Источники

1. [gem5-users] Вопросы о недетерминированных результатах в режиме FS gem5 - Обсуждение в архиве почты
2. [gem5-users] Re: Детерминированность моделирования - Лучшие практики детерминированности
3. [gem5: К моделированию полной системы GPU] - Детерминированность в режиме полной системы
4. [Re: [gem5-users] Источники недетерминированности в полных системных симуляторах] - Источники недетерминированности
5. [Обход ядра в сети на gem5] - Статья об интеграции DPDK
6. [Сетевое взаимодействие в пространстве пользователя в gem5] - Детали интеграции DPDK-gem5
7. [Архитектура 1 Dist-gem5] - Документация по детерминированному выполнению
8. [Обзор архитектуры gem5] - Обзор архитектуры моделирования
9. [Симулятор gem5: Версия 20.0+] - Документация по фреймворку DES

Заключение

Недетерминированное поведение в вашей полной системе моделирования ARM gem5, особенно вариации в количестве TX-пакетов при идентичных контрольных точках, вероятно, вызвано несколькими взаимодействующими факторами:

Зависимости от времени в моделировании сетевых устройств: Чувствительность к времени моделирования сетевых устройств, особенно в передающем пути, является наиболее вероятной причиной. Даже микроскопические временные различия в решениях о передаче пакетов могут накапливаться, влияя на количество TX-пакетов, оставляя RX-счетчики детерминированными.

Сложности интеграции DPDK: Интеграция gem5-dpdk вводит зависимости от времени в обращениях к регистрам и операциях памяти, которые не полностью контролируются базовым детерминированным фреймворком DES.

Вариации времени в модели процессора: Модель процессора ARM O3 создает сложные временные отношения, которые могут влиять на то, когда сетевые операции планируются и выполняются.

Шаблоны управления памятью: Небольшие различия в выделении памяти и времени доступа между запусками могут влиять на эффективность сетевой обработки.

Для улучшения детерминированности рассмотрите возможность реализации более частых стратегических контрольных точек, настройки точности времени в моделях сетевых устройств или изучения подхода с ускорением KVM, упомянутого в литературе, несмотря на вашу текущую чистую настройку DES. Конкретный шаблон детерминированных RX-счетчиков, но переменных TX-счетков strongly указывает на то, что проблема лежит в слое моделирования сетевых устройств, а не в компонентах базового механизма моделирования.