ఒక context switch నిజంగా ఎంత ఖర్చవుతుంది, అది ఎందుకు ముఖ్యం?

Question

IT Interview Practice · Accepted Answer

ఒక **context switch** అనేది kernel ప్రస్తుతం నడుస్తున్న thread యొక్క CPU state (registers, program counter, stack pointer)ను సేవ్ చేసి, మరొక thread దాన్ని పునరుద్ధరించడం, తద్వారా ఒకే core అనేక threadలను 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 కొంతసేపు నెమ్మదిగా నడుస్తుంది, ఎందుకంటే అది తన cacheలను main memory నుండి తిరిగి వేడి చేసుకుంటుంది (miss‌కు పదుల నుండి వందల cycles).

## Thread vs process switch

**ఒకే ప్రాసెస్ యొక్క threadల మధ్య** switching చౌక: అవి ఒక address spaceను పంచుకుంటాయి, కాబట్టి page table (మరియు tagged TLBలు / PCIDలు లేని హార్డ్‌వేర్ మీద TLB) మారాల్సిన అవసరం ఉండదు. **Processలను** switch చేయడం అదనంగా page-table base registerను తిరిగి లోడ్ చేస్తుంది, సంప్రదాయకంగా TLBను flush చేస్తుంది — అందుకే ఎక్కువ ఖర్చవుతుంది.

## ఆచరణలో ఇది ఎందుకు ముఖ్యం

- **చాలా ఎక్కువ threadలు** → scheduler thrash అవుతుంది, పని చేయడం బదులు switch చేయడంలో cyclesను ఖర్చు చేస్తుంది; ఒక పాయింట్ దాటాక, coreల కంటే ఎక్కువ threadలు throughputను *తగ్గిస్తాయి*.
- ఇది **async / event-loop** మోడల్‌ల (Node, nginx, `io_uring`) మరియు **goroutines / green threads** కోసం ప్రధాన వాదన: కొన్ని OS threadలతో అనేక కనెక్షన్‌లను నిర్వహించడం, ప్రతి requestకు ఒక switchను నివారించడం.
- latency-సున్నిత సర్వీస్‌లకు **CPU pinning / affinity** ఎందుకు సహాయపడుతుందో ఇదే — వేడి cacheను కాపాడటానికి ఒక threadను ఒక core మీద ఉంచండి.
- అధిక involuntary context-switch సంఖ్య (`vmstat`, `pidstat`లో కనిపిస్తుంది) lock contention లేదా CPU oversubscription యొక్క క్లాసిక్ లక్షణం.

## ఇది ఎందుకు ముఖ్యం

ఇది senior-level ప్రశ్న, ఎందుకంటే ఇది *పదం* తెలిసినవారిని *ఎందుకు* ఖరీదైనదో అర్థం చేసుకున్నవారి నుండి వేరు చేస్తుంది — మరియు నిజమైన జవాబు (కేవలం register saves కాదు, cache/TLB కాలుష్యం) ఆర్కిటెక్చర్ నిర్ణయాలను నడిపిస్తుంది: thread-per-request కంటే async I/O, coreల సంఖ్యకు thread poolలను సరైన పరిమాణానికి తీసుకురావడం, affinity వాడటం. ఇది scheduling, virtual memory, CPU cachesను ఒకే పెర్ఫార్మెన్స్ కథగా ముడివేస్తుంది.

ఖర్చు ఎక్కడ దాగి ఉంది

Thread vs process switch

ఆచరణలో ఇది ఎందుకు ముఖ్యం

ఇది ఎందుకు ముఖ్యం

సంబంధిత ప్రశ్నలు