In this lesson, you will learn how the Linux scheduler optimizes performance by aligning process placement with the physical architecture of multi-socket memory systems.
The Reality of Non-Uniform Memory Access
In older computer architectures, all CPU cores shared a single pool of RAM equally. However, in modern high-performance servers, we use Non-Uniform Memory Access (NUMA). In a NUMA system, the total system memory is physically partitioned into "nodes." Each CPU socket has its own local bank of memory attached directly to it.
While a CPU can technically access memory located on a different NUMA node (remote memory), doing so is significantly slower because the request must travel across an interconnect bus (like Intel's UPI or AMD's Infinity Fabric). This introduces latency that can bottleneck high-speed applications.
How the Scheduler Responds
To keep performance high, the Linux scheduler tries to maintain processor affinity and memory locality. When a task is first created, the scheduler attempts to place it on a core within the same NUMA node where its memory is currently allocated. If a process starts consuming large amounts of data, the kernel’s memory management unit tracks which node is supplying that memory.
The scheduler uses a concept called NUMA Balancing. Periodically, the kernel inspects task placement:
- It looks at where a process is executing.
- It looks at where that process’s memory resides.
- If the process is "migrating" away from its memory, the scheduler may move the task to a core closer to its data to minimize the performance hit of remote memory access.
Visualizing Affinity
You can see which node a process is interacting with using tools like numastat or by checking its affinity via taskset. If you run a command like:
taskset -p <pid>
You are viewing the CPU mask. If the scheduler is working correctly, it will keep this process within the specific CPU set that corresponds to its primary memory node. By restricting a process to a specific node, you prevent the "ping-pong" effect where a process moves between sockets, constantly invalidating its local CPU cache and triggering slow remote memory fetches.
Key Takeaway: The Linux scheduler prioritizes "locality" by keeping tasks on CPU cores physically closest to the memory they are accessing, minimizing the latency overhead inherent in multi-socket NUMA systems.