एक context switch वास्तव में कितनी कीमत लेता है, और यह क्यों मायने रखता है?

Question

IT Interview Practice · Accepted Answer

एक **context switch** kernel द्वारा वर्तमान में चल रहे thread की CPU state (registers, program counter, stack pointer) को save करना और किसी दूसरे thread की state को restore करना है, ताकि एक अकेला 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** cost कुछ microseconds है। **Indirect** cost — switch के बाद एक cold cache और TLB — अक्सर बड़ा झटका होता है: आने वाला thread कुछ समय तक धीमा चलता है जब वह main memory से अपने caches को फिर से गरम करता है (हर miss पर दसियों से सैकड़ों cycles)।

## Thread बनाम process switch

**एक ही process के threads के बीच** switching सस्ता है: वे एक address space साझा करते हैं, इसलिए page table (और TLB, ऐसे hardware पर जिसमें tagged TLBs / PCIDs नहीं होते) को बदलने की ज़रूरत नहीं। **Processes** switch करना अतिरिक्त रूप से page-table base register को reload करता है और परंपरागत रूप से TLB को flush करता है — यही कारण है कि इसकी कीमत ज़्यादा होती है।

## व्यवहार में यह क्यों मायने रखता है

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

## यह क्यों महत्वपूर्ण है

यह एक senior-स्तरीय सवाल है क्योंकि यह उन लोगों को अलग करता है जो *शब्द* जानते हैं उनसे जो समझते हैं कि यह *क्यों* महँगा है — और असली जवाब (cache/TLB प्रदूषण, केवल register saves नहीं) architectural निर्णयों को दिशा देता है: thread-per-request के बजाय async I/O, thread pools को core गिनती के अनुरूप आकार देना, और affinity का उपयोग। यह scheduling, virtual memory, और CPU caches को एक ही performance कहानी में बाँधता है।

कीमत कहाँ छिपी है

Thread बनाम process switch

व्यवहार में यह क्यों मायने रखता है

यह क्यों महत्वपूर्ण है

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