如何在恢复检查点后在 gem5 中切换 CPU 模型，然后观察差异？
How to switch CPU models in gem5 after restoring a checkpoint and then observe the difference?
我想用轻量级 CPU 在完整系统 (FS) 模式下启动 Linux 内核以节省时间，在启动完成后创建一个检查点，然后用更多的恢复检查点详细 CPU 研究基准，如在：http://gem5.org/Checkpoints
中提到的
但是，当我尝试使用 -r 1 --restore-with-cpu= 时，我无法观察到新旧 CPU 之间的周期差异。
我正在查看的衡量标准是缓存大小如何影响基准测试达到 运行 所需的周期数。
我正在使用的设置在以下位置有详细描述：Why doesn't the Linux kernel see the cache sizes in the gem5 emulator in full system mode? 我正在查看循环计数，因为我目前无法直接使用 Linux 内核查看缓存大小。
例如，如果我使用详细而缓慢的 HPI 模型和命令（摘录）从头开始 Linux 内核：
./build/ARM/gem5.opt --cpu-type=HPI --caches --l1d_size=1024 --l1i_size=1024 --l2cache --l2_size=1024 --l3_size=1024
然后更改缓存大小，随着缓存大小按预期变得更好，基准测试确实变得更快。
但是，如果我第一次启动时没有 --cpu-type=HPI，它使用更快的 AtomicSimpleCPU 模型：
./build/ARM/gem5.opt --caches --l1d_size=1024 --l1i_size=1024 --l2cache --l2_size=1024 --l3_size=1024
然后我用 m5 checkpoint 创建检查点并尝试恢复更快 CPU:
./build/ARM/gem5.opt --restore-with-cpu=HPI -r 1 --caches --l1d_size=1024 --l1i_size=1024 --l2cache --l2_size=1024 --l3_size=1024
然后更改缓存大小没有区别：我总是得到与 AtomicSimpleCPU 相同的循环计数，表明修改后的恢复不成功。
如果我尝试从 AtomicSimpleCPU 切换到 DerivO3CPU，则类似于 x86。
邮件列表中的相关旧线程：http://thread.gmane.org/gmane.comp.emulators.m5.users/14395
测试地点：fbe63074e3a8128bdbe1a5e8f6509c565a3abbd4
--cpu-type=影响恢复，但--restore-with-cpu=没有
我不确定为什么会这样，但我 empirically verified 如果我这样做：
-r 1 --cpu-type=HPI
然后正如预期的那样，缓存大小选项开始影响循环计数：更大的缓存导致更少的循环。
另请记住，缓存不会对 AtomicSimpleCPU 产生太大影响，拥有它们也没有多大意义。
TODO 如果它在我的测试中似乎没有做任何事情，那么 --restore-with-cpu= 与 --cpu-type 的意义何在？
除非让我感到困惑，因为如果 --cpu-type != --restore-with-cpu，那么循环计数将出现在 system.switch_cpus.numCycles 而不是 system.cpu.numCycles.
下
我相信这就是正在发生的事情（尚未测试）：
switch_cpu 包含您切换到 - 当你设置
--restore-with-cpu= != --cpu-type时，它认为你已经
从头开始切换 CPUs
--restore-with-cpu对初始的CPU没有影响。它只是
对于在 运行 本身期间切换 CPU 的选项很重要，例如
--fast-forward 和 --repeat_switch。在这里您会看到 cpu 和 switch_cpu 数据都已填满。
TODO：另外，如果我使用或删除 --restore-with-cpu=，周期会有 1% 的小差异。但为什么会有差异呢？ AtomicSimpleCPU循环计数完全不同，所以一定不是回落到它。
--cpu-type= vs --restore-with-cpu= 出现在 fs.py --fast-forward 中：https://www.mail-archive.com/gem5-users@gem5.org/msg17418.html
确认日志记录发生了什么
使用 CPU 想要的一个很好的理智是启用一些日志记录，如下所示：https://github.com/cirosantilli/linux-kernel-module-cheat/tree/bab029f60656913b5dea629a220ae593cc16147d#gem5-restore-checkpoint-with-a-different-cpu 例如：
--debug-flags ExecAll,FmtFlag,O3CPU,SimpleCPU
shen 看看你是否开始收到 O3 条消息而不是 SimpleCPU 条消息。
通过阅读一些代码，我相信 --restore-with-cpu 专门针对使用非 Atomic CPU 模型创建检查点的情况CPU。脚本假定 AtomicCPU 用于创建检查点。我认为在恢复时拥有与系统检查点相同的 cpu 模型很重要，如果你给另一个模型 --cpu-type 然后它在恢复操作完成后切换到那个模型.
http://gem5.org/Checkpoints#Sampling 有一些关于切换 cpu 模型的（小）细节
首先，对于你的问题，我看不出循环计数是如何指示恢复结果的。无论您要切换什么CPU，正在恢复的周期应该是相同的。切换不会改变过去的周期。创建检查点时，您基本上将模拟冻结在该状态。切换 CPU 只是更改 CPU 的所有参数，同时保持刻度不变。这就像热交换 CPU。
要正确验证还原，您应该在还原前保留一份config.json，并在还原后与新的进行比较。对于 X86 情况，我只能在恢复之前找到字符串 AtomicSimpleCPU。
另外，只有--cpu-type会决定被切换的CPU。但它不会使 --restore-with-cpu 无用。事实上，--restore-with-cpu 只应在使用 CPU 而不是 AtomicSimpleCPU 启动系统时使用。大多数人希望使用 AtomicSimpleCPU 启动系统并创建检查点，因为它更快。但是如果你错误地使用 DerivO3CPU 启动，要恢复这个特定的检查点，你必须将 --restore-with-cpu 配置为 DerivO3CPU。否则会失败。
我想用轻量级 CPU 在完整系统 (FS) 模式下启动 Linux 内核以节省时间，在启动完成后创建一个检查点，然后用更多的恢复检查点详细 CPU 研究基准，如在：http://gem5.org/Checkpoints
中提到的但是，当我尝试使用 -r 1 --restore-with-cpu= 时，我无法观察到新旧 CPU 之间的周期差异。
我正在查看的衡量标准是缓存大小如何影响基准测试达到 运行 所需的周期数。
我正在使用的设置在以下位置有详细描述：Why doesn't the Linux kernel see the cache sizes in the gem5 emulator in full system mode? 我正在查看循环计数，因为我目前无法直接使用 Linux 内核查看缓存大小。
例如，如果我使用详细而缓慢的 HPI 模型和命令（摘录）从头开始 Linux 内核：
./build/ARM/gem5.opt --cpu-type=HPI --caches --l1d_size=1024 --l1i_size=1024 --l2cache --l2_size=1024 --l3_size=1024
然后更改缓存大小，随着缓存大小按预期变得更好，基准测试确实变得更快。
但是，如果我第一次启动时没有 --cpu-type=HPI，它使用更快的 AtomicSimpleCPU 模型：
./build/ARM/gem5.opt --caches --l1d_size=1024 --l1i_size=1024 --l2cache --l2_size=1024 --l3_size=1024
然后我用 m5 checkpoint 创建检查点并尝试恢复更快 CPU:
./build/ARM/gem5.opt --restore-with-cpu=HPI -r 1 --caches --l1d_size=1024 --l1i_size=1024 --l2cache --l2_size=1024 --l3_size=1024
然后更改缓存大小没有区别：我总是得到与 AtomicSimpleCPU 相同的循环计数，表明修改后的恢复不成功。
如果我尝试从 AtomicSimpleCPU 切换到 DerivO3CPU，则类似于 x86。
邮件列表中的相关旧线程：http://thread.gmane.org/gmane.comp.emulators.m5.users/14395
测试地点：fbe63074e3a8128bdbe1a5e8f6509c565a3abbd4
--cpu-type=影响恢复，但--restore-with-cpu=没有
我不确定为什么会这样，但我 empirically verified 如果我这样做：
-r 1 --cpu-type=HPI
然后正如预期的那样，缓存大小选项开始影响循环计数：更大的缓存导致更少的循环。
另请记住，缓存不会对 AtomicSimpleCPU 产生太大影响，拥有它们也没有多大意义。
TODO 如果它在我的测试中似乎没有做任何事情，那么 --restore-with-cpu= 与 --cpu-type 的意义何在？
除非让我感到困惑，因为如果 --cpu-type != --restore-with-cpu，那么循环计数将出现在 system.switch_cpus.numCycles 而不是 system.cpu.numCycles.
我相信这就是正在发生的事情（尚未测试）：
switch_cpu包含您切换到 的 CPU 的统计数据
- 当你设置
--restore-with-cpu= != --cpu-type时，它认为你已经 从头开始切换 CPUs --restore-with-cpu对初始的CPU没有影响。它只是 对于在 运行 本身期间切换 CPU 的选项很重要，例如--fast-forward和--repeat_switch。在这里您会看到 cpu 和 switch_cpu 数据都已填满。
TODO：另外，如果我使用或删除 --restore-with-cpu=，周期会有 1% 的小差异。但为什么会有差异呢？ AtomicSimpleCPU循环计数完全不同，所以一定不是回落到它。
--cpu-type= vs --restore-with-cpu= 出现在 fs.py --fast-forward 中：https://www.mail-archive.com/gem5-users@gem5.org/msg17418.html
确认日志记录发生了什么
使用 CPU 想要的一个很好的理智是启用一些日志记录，如下所示：https://github.com/cirosantilli/linux-kernel-module-cheat/tree/bab029f60656913b5dea629a220ae593cc16147d#gem5-restore-checkpoint-with-a-different-cpu 例如：
--debug-flags ExecAll,FmtFlag,O3CPU,SimpleCPU
shen 看看你是否开始收到 O3 条消息而不是 SimpleCPU 条消息。
通过阅读一些代码，我相信 --restore-with-cpu 专门针对使用非 Atomic CPU 模型创建检查点的情况CPU。脚本假定 AtomicCPU 用于创建检查点。我认为在恢复时拥有与系统检查点相同的 cpu 模型很重要，如果你给另一个模型 --cpu-type 然后它在恢复操作完成后切换到那个模型.
http://gem5.org/Checkpoints#Sampling 有一些关于切换 cpu 模型的（小）细节
首先，对于你的问题，我看不出循环计数是如何指示恢复结果的。无论您要切换什么CPU，正在恢复的周期应该是相同的。切换不会改变过去的周期。创建检查点时，您基本上将模拟冻结在该状态。切换 CPU 只是更改 CPU 的所有参数，同时保持刻度不变。这就像热交换 CPU。
要正确验证还原，您应该在还原前保留一份config.json，并在还原后与新的进行比较。对于 X86 情况，我只能在恢复之前找到字符串 AtomicSimpleCPU。
另外，只有--cpu-type会决定被切换的CPU。但它不会使 --restore-with-cpu 无用。事实上，--restore-with-cpu 只应在使用 CPU 而不是 AtomicSimpleCPU 启动系统时使用。大多数人希望使用 AtomicSimpleCPU 启动系统并创建检查点，因为它更快。但是如果你错误地使用 DerivO3CPU 启动，要恢复这个特定的检查点，你必须将 --restore-with-cpu 配置为 DerivO3CPU。否则会失败。