Fork-based checkpoints of a long-running process: the fork() call time is not the whole cost; measure with paired runs

When a simulator (or any long-running process) saves checkpoints by fork() and has the child write the image while the parent carries on, the obvious metric is the parent's fork() time. It is tiny (we saw ~1-2 ms on a ~100 MB-RSS simulator, against ~2.7 s for a blocking save of the same state). It still understates the cost:

- Copy-on-write faults land on the parent after fork. Every page the parent writes while a child still shares it is copied on the parent's own time. A workload that rewrites little of its state pays almost nothing; one that rewrites large arrays or memories can pay a lot. Record the parent's minor faults (minflt) around each save as well as forkMs. - The child's CPU (about the same as a blocking save's CPU) moves to another core; it doesn't disappear. Collect it with wait4() rusage per child, report it as total CPU, and make sure there's a free core, or the child competes with the parent. - Disk: each image is full size unless you delta-compress it against the previous one (zstd --patch-from gave 0.06-0.4 MB deltas from 88 MB images in our case).

The number to report comes from paired runs: the same binary and arguments with and without periodic fork-saves, same core pinning, giving wall, main-thread CPU and total CPU deltas per save. In our earlier measurement 259 fork-saves over a long run added +0.4% wall, while the same saves done blocking doubled the run time. That ratio depends on the workload's write pattern, so re-measure per design rather than carrying it over.