Here I will complement the perfectly correct information that Paul gave with more gem5 specifics.
One major use case for fast-forwarding is when you have to boot Linux/Android and only then run your content.
The boot could take a very long time compared to your content, and so it is very important to find a way to not run it for every experiment, since you usually need to run several versions of an executable with several different input parameters.
Checkpoint restore also works on gem5's syscall emulation. I had never used it in that case, since there is no boot to skip, but some people have to skip initialization outside of the region of interest.
The solution is to first run content on a less detailed CPU (e.g. the default AtomicSimpleCPU
) and then just before you start running the executable, you switch to a more detailed CPU, e.g. DerivO3CPU
, which is about 5x slower to execute.
gem5 fs.py provides two ways to do this:
--fast-forward <time>
option: runs up to a given time cycles on the first (faster) CPU then switches and continues simulation
-r
+ m5 checkpoint
: you instrument the guest, run boot with the fast CPU, take a checkpoint from instrumentation after init
, and then restore after boot with the slower CPU
Both of those very likely use the exact same internal implementation, except that the checkpoint method has to serialize and serialize state to/from disk.
Of the two approaches, checkpoint restore is much more convenient because:
- you can restore multiple times with different parameters without re-running the boot on the fast CPU
- it is hard to know the right clock time to switch in the first place
Syscall emulation can actually be seen as an alternative fastforwarding approach, as it always dispenses boot, and I've measured a runtime gain of about 2x speed for it at one point with Dhrystone, the downside being that the system is less representative and you have to implement any possibly missing syscalls yourself: https://stackoverflow.com/questions/48986597/when-to-use-full-system-fs-vs-syscall-emulation-se-with-userland-programs-in-gem
For the actual details of which hardware parameters can be modified or not across a restore see: https://stackoverflow.com/questions/60876259/which-system-characteristics-such-as-number-of-cores-of-cache-configurations-can/60876260#60876260
One question that then comes up, is: how can I set different parameters to the program after each restore, if the checkpoint restore restore memory state exactly to what it was? This tutorial covers several possibilities: https://cirosantilli.com/linux-kernel-module-cheat/#gem5-restore-new-script
The information above valid as of gem5 2235168b72537535d74c645a70a85479801e0651, February 2020.