恢复检查点并观察差异后，如何在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

I want to boot the Linux kernel in full system (FS) mode with a lightweight CPU to save time, make a checkpoint after boot finishes, and then restore the checkpoint with a more detailed CPU to study a benchmark, as mentioned at: http://gem5.org/Checkpoints

但是，当我尝试使用-r 1 --restore-with-cpu=时，无法观察到新旧CPU之间的周期差异.

However, when I tried to use -r 1 --restore-with-cpu= I cannot observe cycle differences between the new and old CPU.

我正在考虑的指标是缓存大小如何影响基准测试运行的周期数.

The measure I'm looking at is how cache sizes affect the number of cycles that a benchmark takes to run.

我正在使用的设置在以下位置进行了详细说明:

The setup I'm using is described in detail at: Why doesn't the Linux kernel see the cache sizes in the gem5 emulator in full system mode? I'm looking at the cycle counts because I can't see cache sizes directly with the Linux kernel currently.

例如，如果我使用命令(摘录)使用详细而缓慢的HPI模型从头开始启动Linux内核:

For example, if I boot the Linux kernel from scratch with the detailed and slow HPI model with command (excerpt):

./build/ARM/gem5.opt --cpu-type=HPI --caches --l1d_size=1024 --l1i_size=1024 --l2cache --l2_size=1024 --l3_size=1024 

，然后更改缓存大小，随着缓存大小按预期变好，基准测试的确会变快.

and then change cache sizes, the benchmark does get faster as the cache sizes get better as expected.

但是，如果我第一次启动时没有使用更快的AtomicSimpleCPU模型的--cpu-type=HPI:

However, if I first boot without --cpu-type=HPI, which uses the faster AtomicSimpleCPU model:

./build/ARM/gem5.opt --caches --l1d_size=1024 --l1i_size=1024 --l2cache --l2_size=1024 --l3_size=1024

，然后用m5 checkpoint创建检查点，并尝试还原更快的CPU:

and then I create the checkpoint with m5 checkpoint and try to restore the faster 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相同的周期计数，这表明修改后的还原未成功.

then changing the cache sizes makes no difference: I always get the same cycle counts as I do for the AtomicSimpleCPU, indicating that the modified restore was not successful.

类似于x86，如果我尝试从AtomicSimpleCPU切换到DerivO3CPU.

Analogous for x86 if I try to switch from AtomicSimpleCPU to DerivO3CPU.

邮件列表上的相关旧线程: http://thread .gmane.org/gmane.comp.emulators.m5.users/14395

Related old thread on the mailing list: http://thread.gmane.org/gmane.comp.emulators.m5.users/14395

在以下位置测试:fbe63074e3a8128bdbe1a5e8f6509c565a3abbd4

Tested at: fbe63074e3a8128bdbe1a5e8f6509c565a3abbd4

推荐答案

--cpu-type=影响了还原，但--restore-with-cpu=并没有

--cpu-type= affected the restore, but --restore-with-cpu= did not

我不确定为什么会这样，但是我有凭经验验证如果我这样做:

I am not sure why that is, but I have empirically verified that if I do:

-r 1 --cpu-type=HPI

然后，按预期，缓存大小选项开始影响周期计数:更大的缓存导致更少的周期.

then as expected the cache size options start to affect cycle counts: larger caches leads to less cycles.

还请记住，缓存对AtomicSimpleCPU的影响不大，拥有它们没有多大意义.

Also keep in mind that caches don't affect AtomicSimpleCPU much, and there is not much point in having them.

TODO，如果--restore-with-cpu=与--cpu-type似乎在我的测试中什么都没做，那又有什么意义呢?

TODO so what is the point of --restore-with-cpu= vs --cpu-type if it didn't seem to do anything on my tests?

除了使我困惑，因为如果使用--cpu-type != --restore-with-cpu，则循环计数将显示在system.switch_cpus.numCycles下而不是system.cpu.numCycles下.

Except confuse me, since if --cpu-type != --restore-with-cpu, then the cycle count appears under system.switch_cpus.numCycles instead of system.cpu.numCycles.

我相信这是正在发生的事情(尚未测试):

I believe this is what is going on (yet untested):

• switch_cpu包含您切换到的CPU的统计信息
• 设置--restore-with-cpu= != --cpu-type时，它认为您已经 从一开始就切换CPU
• --restore-with-cpu对初始CPU无效.它只是 对于在运行期间切换CPU的选项很重要，例如 --fast-forward和--repeat_switch.在这里，您会看到cpu和switch_cpu数据都已填满.

• switch_cpu contains stats for the CPU you switched to
• when you set --restore-with-cpu= != --cpu-type, it thinks you have already switched CPUs from the start
• --restore-with-cpu has no effect on the initial CPU. It only matters for options that switch the CPU during the run itself, e.g. --fast-forward and --repeat_switch. This is where you will see both cpu and switch_cpu data get filled up.

TODO:另外，如果我使用或删除--restore-with-cpu=，则周期差异很小1％.但是为什么根本没有区别呢? AtomicSimpleCPU周期数完全不同，因此一定不能回落到它.

TODO: also, if I use or remove --restore-with-cpu=, there is a small 1% cycle difference. But why is there a difference at all? AtomicSimpleCPU cycle count is completely different, so it must not be that it is falling back to it.

--cpu-type=与--restore-with-cpu=出现在fs.py --fast-forward中: 确认日志记录是怎么回事

正在使用想要的CPU的一种很好的方法是启用一些日志记录，如下所示: #gem5-restore-checkpoint-with-a-different-cpu"rel =" nofollow noreferrer> https://github.com/cirosantilli/linux-kernel-module-cheat/tree/bab029f60656913b5dea629a220ae593cc16147d#gem5-restore-checkpoint-与一个不同的CPU 例如:

One good sanity that the CPU want want is being used, is to enable some logging as shown at: https://github.com/cirosantilli/linux-kernel-module-cheat/tree/bab029f60656913b5dea629a220ae593cc16147d#gem5-restore-checkpoint-with-a-different-cpu e.g.:

--debug-flags ExecAll,FmtFlag,O3CPU,SimpleCPU

然后看看您是否开始收到O3消息而不是SimpleCPU消息.

and shen see if you start to get O3 messages rather than SimpleCPU ones.

这篇关于恢复检查点并观察差异后，如何在gem5中切换CPU模型?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！