Computing Library › HPC & Compute
HPC & Compute

Process Affinity and Binding

Affinity pins processes and threads to specific cores and memory so the operating system cannot migrate them and break data locality.

Why binding matters

By default an operating system scheduler may move a thread from one core to another to balance load. On an HPC node that is usually harmful: a migrated thread leaves its warm caches behind and, on a NUMA system, may end up far from its data. Affinity (also called binding or pinning) tells the runtime to keep each process or thread on a fixed set of cores, preserving cache warmth and memory locality.

The mapping decisions

Kronos motion — operating point

Placement involves several linked choices: how many MPI ranks per node, how many threads per rank, and where each lands relative to sockets, cores, and hardware threads (SMT). A common layout puts one rank per NUMA node with threads spread across that node's physical cores. Whether to use both hardware threads of a core (SMT) or only one depends on whether the kernel is latency-bound (SMT can help) or already saturates the core (SMT hurts).

How it is expressed

Job launchers and runtimes provide the controls: MPI launchers offer binding and mapping flags, OpenMP exposes place and binding environment variables, and numactl or scheduler options set memory policy. The right combination is machine-specific and worth measuring, since a poor map can leave cores idle or force cross-socket traffic that halves bandwidth-bound performance.

Diagnosing it

Symptoms of bad affinity include performance that varies run to run, threads clustered on one socket while others sit idle, and remote-memory-heavy profiles. Reporting the actual placement (many launchers can print it) confirms the intended map. For a hybrid Hyperion run, verifying that each rank's threads stay on their NUMA node is a standard step before trusting a scaling measurement.