gem5 - 在 gem5 中恢复检查点时，我可以更改哪些系统特征，例如缓存配置的核心数？

您始终需要考虑的是：某些软件正在运行（例如 Linux 内核），它可能正在将状态存储在描述硬件的内存中。

因此，如果我在恢复过程中突然更改底层硬件，是否会导致软件崩溃，因为它根据之前在内存或其寄存器中收集的信息期待不同的硬件？

作为一般原则，越是“微架构”的东西，运行的软件就越不可能看到它并由于它的变化而崩溃。

因此，要更具体地解决最常见的情况：

CPU 类型：和等 CPU 类型基本上是微架构描述AtomicSimpleCPU，MinorCPU并且DerivO3CPU支持在它们之间切换。甚至有预提交测试断言此功能有效：在 gem5 5ae5fa85d7eb51f4dafdef7e27316d6fc84dedc1 中搜索switcheroo测试。tests/config
缓存：gem5 的经典内存系统不保存任何缓存状态，因此用户在恢复这些检查点时不会陷入预先确定的缓存层次结构配置。此外，在创建检查点时，模拟必须在没有缓存的情况下运行，以便模拟器可以跳过深入的缓存处理。因此，在恢复检查点时，缓存大小、级别和连接的任意组合都是可能的。但是，由于缓存将在空状态下恢复，因此建议在开始获取统计信息之前让模拟预热。

此外，缓存大小目前甚至根本没有向来宾公开：为什么 Linux 内核在完整系统模式下看不到 gem5 模拟器中的缓存大小？所以少了一件可能出错的事情。如果是这样的话，根据缓存大小调整自身的软件可能会根据之前读取的版本进行调整，并且运行速度比预期的要慢，您必须了解该软件并确保不会发生这种情况，即确保软件读取恢复后的缓存大小。

CPU 数量：我很确定 Linux 内核会在早期检查 CPU 数量并对其进行初始化，因此您的软件将无法使用添加的额外 CPU。例如，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 本身是否可以处理添加更多内核，但我运行了一个简单的示例，它并没有立即崩溃。因此，也许如果您能够强制内核重新检查 CPU，它会起作用。

我还会研究内核肯定具有的CPU 热插拔功能，但我敢打赌 gem5 没有实现。如果一切都完美对齐，理论上可以有一个智能恢复机制，在恢复时调用热插拔机制。

作为一个相关问题，我听说某些设置不支持检查点，因为它们不能正确地排出状态：这是其中一个 Ruby 协议的情况，但我现在不记得是哪个。

性能计数器是另一个稍微有趣的案例，作为泄漏微架构的一种方式，但通常软件不会因为性能计数器的意外值而崩溃，并且这些计数器无论如何都应该在感兴趣的区域之前被重置.

根据经验，当不确定是否可以更改模拟对象时，请在其代码（及其基类）中查找serialize()函数的重载。此函数及其对应的unserialize()负责确定在采用检查点时保存和恢复哪个架构状态。

gem5 - 在 gem5 中恢复检查点时，我可以更改哪些系统特征，例如缓存配置的核心数？

问题描述

解决方案

推荐阅读