CPU Affinity

CPU affinity is a scheduling constraint that limits where a task, thread, process or interrupt is allowed to run across available processor cores. The constraint is usually expressed as an affinity mask: the work may run only on the cores included in the mask.

Affinity is used to reduce scheduler migration, preserve cache locality, isolate latency-sensitive paths, keep interrupt handling close to a device, or make a performance test repeatable. It can also create overload if too much work is pinned to the same core.

Affinity Mask

For a task i, define an allowed-core set:

If the set contains one core, the task is pinned. If the set contains several cores, the scheduler may still migrate the task inside that set. A useful review records the mask for tasks, worker pools, interrupt handlers and background services, because one forgotten logging or network thread can invalidate a timing test.

Migration Cost

Let the observed number of migrations be:

over observation time:

The migration rate is:

If each migration has direct and locality cost:

then a first CPU-cost screen is:

This is a lower bound when migrations cause cache misses, NUMA traffic, lock handoff delay or device-interrupt detours.

Worked Migration Screen

Suppose a latency-sensitive service records:

migrations over:

The migration rate is:

If a migration costs:

the direct CPU fraction is:

or:

of one core. The CPU cost is small, but the latency effect can still be large if the migration occurs just before a deadline-sensitive path.

Latency Margin

If a response path has base time:

and migration plus cache warm-up add:

then:

For a deadline:

the margin is:

If pinning reduces cache warm-up to 0.12 ms, the response becomes 1.76 ms and the margin becomes 0.74 ms.

Interference Boundary

The affinity decision should state what interference is being controlled. A compute thread may need to stay close to its cache footprint. A data-acquisition thread may need to share a core with the interrupt that wakes it. A safety monitor may need distance from best-effort logging, compression or network processing.

The boundary also includes what remains movable. If background work can still land on the same core, the affinity mask alone does not prove isolation. If interrupts can migrate away from the pinned thread, locality may improve in one test and disappear after reboot or driver reconfiguration.

Core Budget

Affinity also concentrates load. For a pinned core k, the utilization estimate is:

where U_irq and U_os include interrupts, kernel work and unavoidable background activity on that core.

If:

and the engineering budget is:

the pinning plan is unsafe even if it improves locality. The design moved one risk from migration jitter to core saturation.

Validation Evidence

Useful evidence includes affinity masks, actual CPU residency, migration count, scheduler class, priority, interrupt routing, run-queue length per core, context-switch trace, cache-miss counters, NUMA locality, p95 and p99 wakeup latency, maximum ready-to-running delay and overload behavior with background services enabled.

The validation test should compare unpinned, partially pinned and fully pinned configurations under representative load. The result should report both latency tails and per-core utilization, not just a lower average runtime.

Design Levers

Useful levers include pinning only the critical thread, keeping related interrupt handlers on the same core, isolating a real-time core, limiting worker admission, reducing shared locks, separating noisy background services, and keeping enough spare capacity for operating-system work.

Pinning every thread is rarely a good default. Strong affinity can reduce migration while hiding load imbalance, starving lower-priority work or making failover harder after a core becomes unavailable.

Relationship To Neighbor Terms

Context switch overhead measures part of the cost paid when work changes execution context. CPU affinity controls where that work may run. Preemption latency and release jitter can improve when migrations are removed, but they can worsen if pinned work overloads one core. Thread-pool saturation, lock convoy and task starvation can all be masked or amplified by affinity choices.