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** વચ્ચે switch કરવું સસ્તું છે: તેઓ address space વહેંચે છે, તેથી page table (અને TLB, tagged TLBs / PCIDs વગરના hardware પર) બદલવાની જરૂર નથી. **Processes** switch કરવું વધારામાં page-table base register ને ફરી લોડ કરે છે અને પરંપરાગત રીતે TLB ને flush કરે છે — એટલે જ તે વધુ ખર્ચ કરે છે.

## વ્યવહારમાં તે શા માટે મહત્વનું છે

- **બહુ બધા threads** → scheduler thrash થાય છે, કામ કરવાને બદલે switch કરવામાં cycles ખર્ચે છે; એક બિંદુ પછી, cores કરતાં વધુ threads throughput *ઘટાડે* છે.
- **async / event-loop** મૉડેલ્સ (Node, nginx, `io_uring`) અને **goroutines / green threads** માટે આ મુખ્ય દલીલ છે: થોડા OS threads વડે ઘણા connections સંભાળો, દર request દીઠ switch ટાળીને.
- એટલે જ **CPU pinning / affinity** latency-sensitive services ને મદદ કરે છે — thread ને એક core પર રાખો જેથી તેની ગરમ cache સચવાય.
- ઊંચી involuntary context-switch ગણતરી (`vmstat`, `pidstat` માં દેખાય) એ lock contention કે CPU oversubscription નું classic લક્ષણ છે.

## આ શા માટે મહત્વનું છે

આ senior-સ્તરનો પ્રશ્ન છે કારણ કે તે *શબ્દ* જાણનારાઓને *શા માટે* તે ખર્ચાળ છે તે સમજનારાઓથી અલગ પાડે છે — અને વાસ્તવિક જવાબ (cache/TLB pollution, ફક્ત register saves નહીં) architectural નિર્ણયો ચલાવે છે: thread-per-request કરતાં async I/O, thread pools ને core count પ્રમાણે right-sizing, અને affinity વાપરવું. તે scheduling, virtual memory, અને CPU caches ને એક જ performance વાર્તામાં બાંધે છે.

ખર્ચ ક્યાં છુપાય છે

Thread vs process switch

વ્યવહારમાં તે શા માટે મહત્વનું છે

આ શા માટે મહત્વનું છે

સંબંધિત પ્રશ્નો