Context switch प्रत्यक्षात किती खर्च करतो, आणि तो का महत्त्वाचा आहे?

Question

IT Interview Practice · Accepted Answer

**Context switch** म्हणजे kernel ने सध्या चालू असलेल्या thread ची CPU state (registers, program counter, stack pointer) जतन करणे आणि दुसऱ्या thread ची पुनर्स्थापित करणे, जेणेकरून एक core अनेक threads multiplex करू शकतो. तो प्रत्येक scheduler preemption, blocking syscall, किंवा interrupt वर घडतो — आणि तो फुकट नाही.

## खर्च कुठे लपतो

```text
DIRECT cost (visible, ~1–5 µs):
  save/restore registers · run scheduler logic · switch kernel stacks
  if PROCESS switch: also swap page tables (CR3) → FLUSHES the TLB

INDIRECT cost (often much larger):
  cold CPU CACHES → the new thread's data isn't in L1/L2/L3 → cache misses to RAM
  cold TLB        → address translations must be re-walked
  lost pipeline / branch-predictor state
```

**थेट (direct)** खर्च काही microseconds आहे. **अप्रत्यक्ष (indirect)** खर्च — switch नंतरची थंड cache आणि TLB — वारंवार मोठा फटका असतो: येणारा thread काही काळ संथ चालतो कारण तो main memory मधून त्याची caches पुन्हा गरम करतो (प्रति miss दहा ते शेकडो cycles).

## Thread vs process switch

**एकाच process च्या threads** दरम्यान switching स्वस्त आहे: ते एक address space सामायिक करतात, त्यामुळे page table (आणि TLB, tagged TLBs / PCIDs नसलेल्या हार्डवेअरवर) बदलण्याची गरज नाही. **Processes** switch करताना अतिरिक्तपणे page-table base register पुन्हा load होते आणि पारंपरिकपणे TLB flush होते — म्हणूनच त्याला अधिक खर्च येतो.

## प्रत्यक्षात ते का महत्त्वाचे आहे

- **खूप जास्त threads** → scheduler thrash होतो, काम करण्याऐवजी switching मध्ये cycles घालवतो; एका बिंदूनंतर, cores पेक्षा जास्त threads throughput *कमी* करतात.
- हा **async / event-loop** मॉडेल्स (Node, nginx, `io_uring`) आणि **goroutines / green threads** साठीचा मुख्य युक्तिवाद आहे: कमी OS threads सह अनेक connections हाताळा, प्रति request एक switch टाळा.
- यामुळेच **CPU pinning / affinity** latency-संवेदनशील services ना मदत करते — thread ची गरम cache जपण्यासाठी तो एका core वर ठेवा.
- उच्च involuntary context-switch संख्या (`vmstat`, `pidstat` मध्ये दिसणारी) हे lock contention किंवा CPU oversubscription चे classic लक्षण आहे.

## हे का महत्त्वाचे आहे

हा एक senior-स्तराचा प्रश्न आहे कारण तो *संज्ञा* माहीत असणाऱ्यांना *तो का महाग आहे* हे समजणाऱ्यांपासून वेगळे करतो — आणि खरे उत्तर (cache/TLB प्रदूषण, फक्त register saves नव्हे) architectural निर्णय ठरवते: thread-per-request ऐवजी async I/O, core संख्येनुसार thread pools चा योग्य आकार, आणि affinity वापरणे. तो scheduling, virtual memory, आणि CPU caches यांना एका performance कथेत बांधतो.

खर्च कुठे लपतो

Thread vs process switch

प्रत्यक्षात ते का महत्त्वाचे आहे

हे का महत्त्वाचे आहे

संबंधित प्रश्न