Context Switching (CS) is a valuable service provided by the underlying Operating System. It prevents greedy processes from CPU hogging, time-shares CPU between multiple threads/tasks/processes to create an illusion of continuous progress. However, the suspension of the first process and scheduling of the second one requires the kernel to store the state of the first process and load the state of the second one. The overhead and time required for the same is referred to as context switching overhead.
Why bother?
- With increasing context switching the probability of context data available in CPU’s cache is small and therefore needs to be fetched from main memory which is way more costly operation than fetching the same data from CPU cache. Further, the currently resident data in CPU cache needs to be committed to RAM. Together, these two operation per context switch make the problem grave.
- Increases the general user space processing. A typical user space that requires instructions and data from CPU L1/L2 cache will now need to fetch the same data from main memory.
- Increases latency for the process as explained above.
How to interpret data?
CS can be classified as below;
- Voluntary – context switch can be triggered by the process making itself unrunnable, such as by waiting for an I/O or synchronization operation to complete. Thus, this value can be used to infer frequency of blocking calls in your application process.
- Hints: think non blocking, asynchronous, reactive modes
- Pre-emptive/Non-Voluntary – signify processes contending for the CPU and having to be switched out even though their task had not completed. Simply put, there are far too many threads than necessary.
- Hints: reduce threads, use thread pools, reduce task granularity
| Reference: | JVM Pressure – Context Switching Overhead from our JCG partner Nitin Tripathi at the ZERO blog. |
