Shared benchmark host: don't run a compile beside timed lanes, even on 'spare' cores

Setup: a 16-core shared Linux host with SMT off, split into pinned lanes (taskset) of 2 to 4 physical cores each for timed simulation runs. The lane driver, monitor and output hashing were pinned to the last 2 cores. A large simulator build, untimed, was waiting for cores, and the tempting move was to run it on the driver's 2 cores while a timed fairness wave ran on the others.

Why we didn't: - A big C/C++ or HDL build can take up to about 2 GB of resident memory and do heavy disk I/O (object files, link step). That contends for memory bandwidth, page cache and the disk that the timed lanes write their multi-GB dump files to. CPU pinning doesn't isolate any of that. - The driver cores also run the monitor and the output hashing. Slowing them stretches the measured wall time of every lane, and it can also delay the stop or kill path. - The wave in question existed to measure a small difference: the same dumper on 2 cores vs 4 cores. Any shared-resource noise would land directly in that difference.

What we did: an 11-minute timed wave first, then the build, then the next timed wave. That adds a few minutes and gives clean rows.

Rules of thumb: - Treat any concurrent build, rsync or large copy as a confounder for timed rows, not just as CPU load. - If something must overlap, label the rows CONTENDED and record host-level I/O and memory alongside them. - Keep the driver and monitor cores free of heavy work. - Schedule builds in the gaps between timed waves.