एउटा context switch ले वास्तवमा के खर्च गर्छ, र यो किन महत्त्वपूर्ण छ?

Question

IT Interview Practice · Accepted Answer

**Context switch** भनेको kernel ले हाल चलिरहेको thread को CPU state (register, program counter, stack pointer) सुरक्षित गरेर अर्को thread को restore गर्नु हो, ताकि एउटै 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
```

**प्रत्यक्ष** लागत केही microsecond हो। **अप्रत्यक्ष** लागत — switch पछिको चिसो cache र TLB — प्रायः ठूलो प्रहार हुन्छ: भित्रिने thread केही बेर सुस्त चल्छ किनभने यसले main memory बाट आफ्ना cache पुनः न्यानो पार्छ (प्रति miss दशौं देखि सयौं cycle)।

## Thread बनाम process switch

**एउटै process का thread हरूबीच** switch गर्नु सस्तो हुन्छ: तिनले address space साझा गर्छन्, त्यसैले page table (र TLB, tagged TLB / PCID नभएको hardware मा) परिवर्तन गर्नु पर्दैन। **Process हरू** switch गर्दा थपमा page-table base register पुनः load हुन्छ र परम्परागत रूपमा TLB flush हुन्छ — त्यसैले यो बढी महँगो पर्छ।

## व्यवहारमा यो किन महत्त्वपूर्ण छ

- **धेरै thread** → scheduler thrash हुन्छ, काम गर्नुभन्दा switch गर्नमा cycle खर्च गर्छ; एउटा बिन्दु नाघेपछि, core भन्दा बढी thread ले throughput *घटाउँछ*।
- यो **async / event-loop** model हरू (Node, nginx, `io_uring`) र **goroutine / green thread** का लागि मुख्य तर्क हो: थोरै OS thread ले धेरै connection सम्हाल्ने, प्रति request एउटा switch नगरी।
- यही कारण **CPU pinning / affinity** ले latency-sensitive service हरूलाई मद्दत गर्छ — एउटा thread लाई एउटै core मा राख्नुहोस् ताकि यसको न्यानो cache जोगियोस्।
- उच्च involuntary context-switch गणना (`vmstat`, `pidstat` मा देखिने) lock contention वा CPU oversubscription को उत्कृष्ट लक्षण हो।

## यो किन महत्त्वपूर्ण छ

यो एउटा senior-स्तरको प्रश्न हो किनभने यसले *शब्द* जान्ने मानिसहरूलाई *किन* यो महँगो छ भन्ने बुझ्नेहरूबाट छुट्याउँछ — र वास्तविक जवाफ (cache/TLB प्रदूषण, केवल register save मात्र होइन) ले architectural निर्णय निर्देशित गर्छ: thread-per-request भन्दा async I/O, thread pool लाई core सङ्ख्या अनुसार सही आकार दिने, र affinity प्रयोग गर्ने। यो scheduling, virtual memory, र CPU cache लाई एउटै performance कथामा बाँध्छ।

लागत कहाँ लुक्छ

Thread बनाम process switch

व्यवहारमा यो किन महत्त्वपूर्ण छ

यो किन महत्त्वपूर्ण छ

सम्बन्धित प्रश्नहरू