Gem5 checkkpoint使用： checkpoint恢复并运行parsec benchmark，运行和checkpoint时不同的新script

简介

Gem5 checkkpoint使用： 如何保存checkpoint，从checkpoint恢复，使用哪一层级的文件夹作为输入，-r 1制定检查点 顺序，并运行parsec benchmark。尤其提供运行和checkpoint时不同的新script的方法。不然每一次restore依旧是运行检查点创建时的脚本，就失去了检查点的加速意义（因为不能通用的跳过系统启动部分，给未知的不同的用途使用）。我们改动了hack_back_ckpt.rcs 在2023年可以使用，可以给任意生成检查点时未知的脚本提供检查点。新的脚本可以直接从这个检查点启动。

生成checkpoint

./build/X86/gem5.opt -d m5out/onlyoneCPUkvmCheckPointDifferRCS20231218  configs/deprecated/example/fs.py --kernel=/home/yz/.cache/gem5/x86-linux-kernel-4.19.83 --disk=/home/yz/.cache/gem5/x86-parsec   --cpu-type=X86KvmCPU   --num-cpus=1  --script=configs/boot/yzhack_back_ckpt.rcS
# kvm 模式如果报错perf的问题，试试下面
#sudo sysctl kernel.perf_event_paranoid=1 

耗时大概十几秒。因为我们用的X86KvmCPU，相当与用的物理机器。X86KvmCPU的结果会不准，但是我们也不关心，因为checkpoint之前的结果我们是需要跳过，不进行统计的。
结果的文件夹内会有一个cpt文件夹。名字是当前tick数。

restore with checkpoint 并且引入new script

./build/X86/gem5.opt -d m5out/onlyoneCPUkvmCheckPointDifferRCS20231218restore  configs/deprecated/example/fs.py --script=configs/yz2023Nov/small_n2/yzfs_canneal.script --kernel=/home/yz/.cache/gem5/x86-linux-kernel-4.19.83 --disk=/home/yz/.cache/gem5/x86-parsec --checkpoint-dir=m5out/onlyoneCPUkvmCheckPointDifferRCS20231218    -r 1  --restore-with-cpu=X86KvmCPU  --cpu-type=TimingSimpleCPU   --num-cpus=1   --script=configs/yz2023Nov/yzfs_parsec.script

从checkpoint恢复也需要几秒。 --restore-with-cpu=X86KvmCP可以选用尽可能快的，因为这只在恢复这个过程中使用。然后恢复好之后，接下来运行的通过–cpu-type=TimingSimpleCPU指定。

就可以看到进入了 tick 11768729380500，这也是我checkpoint文件夹cpt.11768729380500的名字。

注意，这里给的目录–checkpoint-dir=m5out/onlyoneCPUkvmCheckPointDifferRCS20231218 是cpt.11768729380500上级目录，不要给到m5out/onlyoneCPUkvmCheckPointDifferRCS20231218/cpt.11768729380500/这一级， -r 1 因为我们只有一个checkpoint文件（夹），所以-r 1 选第一个。

然后运行新脚本

每一次checkpoint都是fixed disk，意味着我们restore的文件是固定的，脚本命令也是固定的。 restore 时候指定的 --script=configs/yz2023Nov/yzfs_parsec.script并不会自动运行，而只是被加载进去。 但是restore的时候，依旧会执行制造检查点时的脚本命令而忽略恢复时的新加入的不同的脚本命令。

所以我们要在制造检查点的时候就预先判断需要换脚本，逻辑大概如下：

#如果不预判
checkpoint： run script_A
restore: load script but continue run scirpt_A
# what we observe when restore: the script doesn't make sense. always m5 exit.

#如果预判
checkpoint： run script_A  updated script_A to be script_B  run script_B # but script_A=script_B as it is not changed when creat checkpoint 
restore:  continue run scirpt_A, updated script_A to be script_B  run script_B   # but script_B is new as we will provide the new script if we don't provide new script, it will be the same as originial checkpoint's script.
# what we observe when restore: the script_B content is different.

具体的细节会单独有一篇博客讲述，这里就讲两个关键点：

/sbin/m5 readfile > /tmp/runscript
cat /tmp/runscript 
echo "yzzzzzz54oading second new script..."
/sbin/m5 readfile > /tmp/runscript
cat /tmp/runscript

1. 重复load 来更新成scriptB。 原版的只load了一次，echo的值会不一样。
2. echo显示
   结果： 当我们./util/term/m5tern 3456 时，输出如下：
   
   这证明了老脚本被执行了。
   
   这证明了新script是成功加载了的。

小结

核心是,创建checkpoint时要用特定的script文件,这个文件会让gem5恢复后读取新的任意输入script并执行. 在使用checkpoint恢复时, 输入提供的脚本文件,则会被执行.
关键点在于,创建checkpoint时的script文件提前计划好了会更换新的script文件.