What is Processor Affinity?
Processor affinity explained — soft vs hard affinity, sched_setaffinity, and why cache locality matters — interview-ready answer.
Expected Interview Answer
Processor affinity is the tendency, or explicit configuration, for a process or thread to keep running on the same CPU core it ran on before, so it can keep reusing the cache state that core already holds instead of paying the cost of warming up a cache on a different core.
Soft affinity is what a scheduler does by default: it prefers to reschedule a thread back onto the core it last ran on, purely as a heuristic, but will freely move it elsewhere if that core is busy. Hard affinity is an explicit constraint set by a program or administrator — using calls like sched_setaffinity on Linux — that pins a thread to a specific core or set of cores, and the scheduler is not allowed to run it anywhere else even if that means the pinned core is momentarily busier than others. Affinity exists because migrating a thread to a cold core forces a cache warm-up (and on NUMA systems, potentially remote memory access), so keeping threads local usually improves throughput, but hard-pinning too many threads can hurt load balancing by preventing the scheduler from evening out queue lengths. It is commonly used to isolate latency-sensitive threads (like an audio or trading thread) from noisy neighbors, or to keep interrupt handling for a specific device pinned to one core.
- Preserves cache-warm state, reducing cache-miss overhead on migration
- Distinguishes soft affinity (a scheduler heuristic) from hard affinity (an explicit pin)
- Explains a real production tool: sched_setaffinity / taskset on Linux
- Connects directly to NUMA and load-balancing tradeoffs
AI Mentor Explanation
Processor affinity is like a captain preferring to send the same fielder back to the same fielding position after a drinks break, since that fielder already knows the pitch conditions there — that is soft affinity, a preference the captain can override if needed. Hard affinity is like a rule that a specific fielder must always field at deep square leg no matter what, even if another position needs covering more urgently. The soft preference improves familiarity without rigidity; the hard rule guarantees position-specific expertise at the cost of tactical flexibility.
Step-by-Step Explanation
Step 1
Scheduler default: soft affinity
On reschedule, the scheduler prefers placing a thread back on the core it last ran on, as a cache-friendly heuristic.
Step 2
Heuristic can be overridden
If the preferred core is busy, soft affinity yields and the scheduler places the thread on a different, less busy core.
Step 3
Explicit hard affinity request
A program or admin calls sched_setaffinity (or taskset) to pin a thread to a specific CPU mask.
Step 4
Scheduler honors the pin
The scheduler is now constrained to only run that thread on the pinned cores, even if it creates local imbalance.
What Interviewer Expects
- A clear distinction between soft affinity (heuristic) and hard affinity (explicit pin)
- Understanding that cache-warm state is the reason affinity matters
- Knowledge of a real API/tool like sched_setaffinity or taskset
- Awareness that hard-pinning trades load-balancing flexibility for locality guarantees
Common Mistakes
- Treating affinity as always mandatory rather than distinguishing soft vs hard
- Not connecting affinity to cache-warm state or NUMA locality
- Assuming pinning threads is always a performance win with no downside
- Confusing processor affinity with process priority
Best Answer (HR Friendly)
“Processor affinity is the idea of keeping a program running on the same CPU core it used before, because that core already has relevant data cached and switching cores means starting that caching over again. Sometimes it is just a soft preference the scheduler applies automatically, and sometimes a developer explicitly pins a thread to a specific core when performance consistency really matters, like for audio or trading applications.”
Code Example
#define _GNU_SOURCE
#include <sched.h>
#include <pthread.h>
void pin_current_thread_to_core(int core_id) {
cpu_set_t cpu_mask;
CPU_ZERO(&cpu_mask);
CPU_SET(core_id, &cpu_mask); /* only this core is allowed */
/* Hard affinity: the scheduler may not run this thread anywhere else */
pthread_setaffinity_np(pthread_self(), sizeof(cpu_mask), &cpu_mask);
}Follow-up Questions
- What is the difference between soft affinity and hard affinity?
- Why does migrating a thread to a different core hurt cache performance?
- How does processor affinity interact with load balancing on a busy system?
- When would pinning an interrupt handler to a specific core make sense?
MCQ Practice
1. What is “soft” processor affinity?
Soft affinity is just a scheduling preference — the scheduler favors the previous core but will migrate the thread elsewhere if needed.
2. What system call sets hard processor affinity on Linux?
sched_setaffinity() (or pthread_setaffinity_np for threads) pins a thread to a specific CPU mask, which the scheduler must respect.
3. Why does affinity generally improve performance?
Keeping a thread on the same core lets it reuse cached data rather than paying a cache warm-up cost after migration.
Flash Cards
What is processor affinity? — The tendency or configuration to keep a thread running on the same CPU core to reuse cache-warm state.
Soft vs hard affinity? — Soft: a scheduler preference that can be overridden. Hard: an explicit pin the scheduler must obey.
What Linux call sets hard affinity? — sched_setaffinity() (or pthread_setaffinity_np for threads); taskset from the shell.
Downside of over-pinning threads? — It can hurt load balancing by preventing the scheduler from evening out core queue lengths.