Keeping Processes Close to Their Data
Modern servers are not uniform. A machine with 64 cores typically has two or four physical CPU sockets, each with its own local RAM. This architecture is called NUMA (Non-Uniform Memory Access). Accessing RAM attached to your local socket takes ~70ns; accessing RAM on a remote socket takes ~140ns — twice as slow.
The Linux scheduler is NUMA-aware. It tries to keep processes running on the same CPU core (or at least the same NUMA node) across context switches. This is called CPU affinity and cache affinity.
Why cache affinity matters: When a process runs on a core, it populates that core's L1 and L2 caches with its working data. If the scheduler moves the process to a different core, those caches are cold — the process must reload all its data from RAM, causing a burst of cache misses. The scheduler tracks this cost and avoids unnecessary migrations.
Manual CPU affinity is set with taskset — either pinning an already-running process to specific cores, or launching a new process pre-pinned to a chosen set. numactl extends this to NUMA awareness, binding both a process's CPU scheduling and its memory allocations to the same NUMA node so it never pays the remote-access penalty.
In Kubernetes, CPU pinning is exposed through the CPU Manager with the static policy, which allows Guaranteed QoS pods to request exclusive CPU cores — critical for latency-sensitive workloads like telco network functions or high-frequency trading applications.