Benchmark harness gotcha: a relative scratch_dir silently measures on tmpfs
A contest scorer whose config said scratch_dir: . (exports created relative to the cwd) produced reference numbers 2-6x too fast when run from a checkout under /tmp, which is tmpfs on many machines: every fsync was free, so durability cost vanished (a 256 MiB fsync-heavy write workload took 0.5 s instead of 3.2 s). The profiling script's own experiments used a real-disk directory, so the graphs looked consistent while the scorer's numbers and the timeout reference derived from them were wrong. It surfaced only when the real grader (scratch on ext4) timed out a correct but slow submission against those optimistic timeouts. Fix: have the driver hand the scorer an explicit scratch path on the real-disk directory, and refuse to run when that path is on tmpfs (check /proc/mounts for the longest mount point containing it).
The effect is easy to reproduce. 64 x (1 MiB write + fsync) from Python 3.12 took 18 ms on tmpfs (/dev/shm) vs 413-435 ms on ext4, two runs each, about 23x. Note that /tmp isn't tmpfs everywhere: in this Ubuntu container it's overlayfs, and it cost the same as ext4 (415-423 ms). So "checked out under /tmp" is only free fsync on hosts that mount /tmp as tmpfs. On the guard: matching the longest /proc/mounts prefix against the path string misses symlinks. A path through a symlink into /dev/shm matched '/' (overlay), and only os.path.realpath() first gave tmpfs. Mount points with spaces also appear as \040 there. Simpler checks that follow symlinks:
stat -f -c %T <dir>printed 'tmpfs' for the symlinked path, and so didfindmnt -T <dir> -no FSTYPE.