Benchmark: auto-pin threads when CPU affinity is restricted

[HFTrader]

Summary

When the benchmark process has restricted CPU affinity (via taskset, cpuset, or container --cpuset-cpus), automatically pin each thread to its own physical core.

• Detects restricted affinity by comparing sched_getaffinity against online CPU count
• Reads HT sibling topology from sysfs thread_siblings_list — two benchmark threads never share a physical core
• Errors out with a clear message if fewer physical cores are available than --num-threads
• When affinity is unrestricted, behavior is unchanged (no pinning)

Motivation

Container runtimes (podman/docker) with --cpuset-cpus do not remap CPU numbers. Inside a container restricted to CPUs 9-11, the kernel still uses host CPU IDs. Code that assumes numbering starts at 0 and calls sched_setaffinity(cpu=0) gets EINVAL — silently, if the return value isn't checked. All threads then run unpinned, potentially timesharing a single core, producing bogus benchmark results.

By reading the actual affinity mask and pinning to those real CPU IDs, this issue is avoided. Usage:

# Threads auto-pin to one physical core each:
taskset -c 9-11 ./universal_benchmark --num-threads 3 --reads 100 ...

# No taskset = no pinning (current behavior preserved):
./universal_benchmark --num-threads 8 --reads 100 ...

Test plan

• Unrestricted affinity: no pinning, current behavior
• taskset -c 0-2: auto-pins 2 threads to CPUs 0, 1
• taskset -c 0,4 (HT siblings on test machine): errors with "Need 2 physical cores but only 1 available"
• All unit tests pass
• Linux only; non-Linux platforms skip pinning gracefully