In this lesson, you will learn why moving a process from one CPU core to another causes a performance hit known as Task Migration Overhead.
The Cost of "Moving House"
In modern multi-core systems, each physical CPU core has its own high-speed local memory called a cache (L1 and L2). When a task runs on a specific core, it fills that local cache with the data and instructions it needs most frequently. This is known as "cache locality."
When the Linux scheduler decides to move a task from one core to another—perhaps to balance the load across the system—the task effectively "moves house." Suddenly, the data the task needs is no longer in the local cache of the new core. The CPU must then fetch that data from slower main memory (RAM) or from the cache of the previous core. This delay is the migration overhead.
Why It Matters
While the scheduler aims for fairness, moving a task too frequently (a phenomenon called "ping-ponging") results in constant cache misses. The CPU spends more time waiting for data to arrive from memory than actually executing instructions.
Consider a scenario where a thread performs heavy calculations on a large array:
// If this loop is migrated between cores, the CPU must
// constantly reload the array data into the new cache.
for (int i = 0; i < 1000000; i++) {
data[i] = compute(data[i]);
}
If the scheduler migrates this thread mid-loop, the new core finds an "empty" cache. The performance degradation is most severe in memory-intensive applications where the speed of execution relies on keeping "hot" data as close to the execution unit as possible.
Minimizing the Impact
Linux tries to be "cache-aware" by keeping a task on the same core for as long as possible unless the load imbalance is significant. By preferring the core that already has the task's data, the scheduler reduces the number of expensive cache-refill cycles. Understanding this overhead is essential when debugging why a perfectly balanced system might still feel sluggish during high-intensity tasks.
Key Takeaway: Task migration forces the CPU to discard cached data and perform costly memory fetches, leading to a temporary performance dip that the Linux scheduler works to minimize.