რას ჯდება რეალურად context switch და რატომ არის ეს მნიშვნელოვანი?

Question

IT Interview Practice · Accepted Answer

**Context switch** არის kernel-ის მიერ ამჟამად მომუშავე thread-ის CPU მდგომარეობის (register-ები, program counter, stack pointer) შენახვა და სხვა thread-ის აღდგენა, ისე რომ ერთმა core-მ ბევრი thread ამრავალხაზოვნოს. ის ხდება ყოველ 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
```

**პირდაპირი** ღირებულება რამდენიმე მიკროწამია. **არაპირდაპირი** ღირებულება — ცივი cache და TLB switch-ის შემდეგ — ხშირად უფრო დიდი დარტყმაა: შემომავალი thread ცოტა ხანს ნელა მუშაობს, სანამ თავის cache-ებს მთავარი მეხსიერებიდან ხელახლა ათბობს (ათობით-ასობით cycle თითო miss-ზე).

## Thread vs process switch

**ერთი process-ის thread-ებს შორის** გადართვა უფრო იაფია: ისინი იზიარებენ address space-ს, ამიტომ page table (და TLB, hardware-ზე tagged TLB / PCID-ის გარეშე) არ უნდა შეიცვალოს. **Process-ების** გადართვა დამატებით ხელახლა ტვირთავს page-table base register-ს და ტრადიციულად flush-ს უკეთებს TLB-ს — რის გამოც ის მეტს ჯდება.

## რატომ არის ეს მნიშვნელოვანი პრაქტიკაში

- **მეტისმეტად ბევრი thread** → scheduler thrash-ს იწყებს, cycle-ებს ხარჯავს გადართვაზე და არა მუშაობაზე; გარკვეული ზღვრის შემდეგ core-ებზე მეტი thread *ამცირებს* throughput-ს.
- ეს არის ძირითადი არგუმენტი **async / event-loop** მოდელებისთვის (Node, nginx, `io_uring`) და **goroutine-ებისთვის / green thread-ებისთვის**: ბევრი კავშირის დამუშავება მცირე OS thread-ებით, თითო request-ზე გადართვის თავიდან აცილებით.
- ეს არის ის, რის გამოც **CPU pinning / affinity** ეხმარება latency-ისადმი მგრძნობიარე service-ებს — thread-ის ერთ core-ზე შენარჩუნება მისი თბილი cache-ის შესანარჩუნებლად.
- involuntary context-switch-ის მაღალი რაოდენობა (ხილული `vmstat`-ში, `pidstat`-ში) lock contention-ის ან CPU-ის ზედმეტი გამოწერის (oversubscription) კლასიკური სიმპტომია.

## რატომ არის ეს მნიშვნელოვანი

ეს senior-დონის კითხვაა, რადგან ის აშორებს იმ ადამიანებს, ვინც *ტერმინს* იცის, მათგან, ვისაც ესმის *რატომ* არის ის ძვირი — და რეალური პასუხი (cache/TLB-ის დაბინძურება და არა მხოლოდ register-ების შენახვა) განაპირობებს არქიტექტურულ გადაწყვეტილებებს: async I/O thread-per-request-ის ნაცვლად, thread pool-ის სწორ ზომაზე მორგება core-ების რაოდენობასთან და affinity-ის გამოყენება. ის აკავშირებს scheduling-ს, virtual memory-სა და CPU cache-ებს ერთ წარმადობის ისტორიაში.

სად იმალება ღირებულება

Thread vs process switch

რატომ არის ეს მნიშვნელოვანი პრაქტიკაში

რატომ არის ეს მნიშვნელოვანი

დაკავშირებული კითხვები