Что вы всегда должны думать: какое-то программное обеспечение работает (например, Linux ядро), и оно может сохранять состояние в памяти, которое описывает аппаратное обеспечение.
Поэтому, если я сделаю внезапное изменение к базовому оборудованию во время восстановления, может ли это привести к взрыву программного обеспечения, потому что оно ожидает другое оборудование, основанное на предыдущей информации, которую оно собрало в памяти или своих регистрах?
Как правило, чем больше «микроархитектура» что-то, тем меньше вероятность того, что работающее программное обеспечение увидит его и взорвется из-за его изменения.
Таким образом, чтобы более конкретно рассмотреть наиболее распространенные случаи:
CPU type: типы CPU, такие как AtomicSimpleCPU, MinorCPU и DerivO3CPU, являются в основном микроархитектурными описаниями, и переключение между ними хорошо поддерживается. Даже тесты до фиксации утверждают, что эта функция работает: поиск switcheroo тестов в tests/config, например, в gem5 5ae5fa85d7eb51f4dafdef7e27316d6fc84dedc1.
кэши: gem5's Система памяти classi c не сохраняет никакого состояния кэша, поэтому пользователь не застревает в заранее определенной конфигурации иерархии кэша при восстановлении этих контрольных точек. Кроме того, при создании контрольных точек симуляция должна выполняться без кэшей, чтобы симулятор мог пропустить углубленную обработку кэша. Поэтому при восстановлении контрольных точек возможна любая комбинация размеров, уровней и подключений кеша. Однако, поскольку кэши будут восстановлены в пустом состоянии, рекомендуется разрешить имитацию прогрева до того, как начнется получение статистики.
Более того, размеры кэша в настоящее время даже не предоставляются гостю, как кажется: Почему ядро Linux не видит размеры кеша в эмуляторе gem5 в режиме полной системы? , так что это еще одна вещь, которая может go ошибаться. Если бы это было так, программное обеспечение, которое настраивалось в зависимости от размеров кэша, могло бы настраиваться на основе ранее прочитанной версии и работать медленнее, чем ожидалось, вы должны были бы понять это программное обеспечение и убедиться, что этого не происходит, то есть убедиться, что программное обеспечение считывает размеры кеша после восстановления.
количество процессоров: Я почти уверен, что ядро Linux проверяет количество процессоров и инициализирует их на ранних этапах, поэтому ваше программное обеспечение не сможет использовать добавлены дополнительные процессоры. Например, загрузочные журналы aarch64 Linux 5.4.3 относительно рано при загрузке инициализации вторичного ядра:
<6>[ 0.051463] smp: Bringing up secondary CPUs ...
<6>[ 0.055387] Detected PIPT I-cache on CPU1
<6>[ 0.056322] CPU1: Booted secondary processor 0x0000000001 [0x000f0510]
<6>[ 0.062014] Detected PIPT I-cache on CPU2
<6>[ 0.062172] CPU2: Booted secondary processor 0x0000000002 [0x000f0510]
<6>[ 0.065890] Detected PIPT I-cache on CPU3
<6>[ 0.066051] CPU3: Booted secondary processor 0x0000000003 [0x000f0510]
<6>[ 0.066689] smp: Brought up 1 node, 4 CPUs contains
<6>[ 0.066771] SMP: Total of 4 processors activated.
Я не уверен, что сам gem5 может справиться с добавлением большего количества ядер, но я запустил Простой пример, и он не взорвался сразу. Так что, возможно, если бы вы смогли заставить ядро перепроверить процессоры, это сработало бы.
Я бы также рассмотрел возможности горячего подключения ЦП, которые ядро определенно имеет , но которые Держу пари, что gem5 не реализуется. Если бы все было идеально выровнено, теоретически было бы возможно иметь интеллектуальный механизм восстановления, который вызывает механизмы горячего подключения во время восстановления.
В качестве связанной проблемы я слышал, что некоторые настройки не поддерживают взятие контрольных точек, потому что они не могут правильно истощать состояние: это имело место для одного из Ruby протоколы, но я не помню какой именно сейчас.
Счетчики производительности - это еще один немного интересный случай, который приходит на ум как способ утечки микроархитектуры, но обычно программное обеспечение не взрывается из-за неожиданных значений счетчиков производительности, и эти счетчики должны быть сброшены. в любом случае перед интересующей областью.
Как правило, если сомневаетесь, можно ли изменить объект моделирования, посмотрите в его коде (и его базовых классах) перегрузку сериализации . () функция. Эта функция вместе с ее unserialize () аналогом отвечает за определение того, какое архитектурное состояние сохраняется и восстанавливается при взятии контрольной точки.