context switch มีต้นทุนจริง ๆ เท่าไร และทำไมมันจึงสำคัญ?

Question

IT Interview Practice · Accepted Answer

**context switch** คือการที่ kernel บันทึกสถานะ CPU ของเธรดที่กำลังทำงานอยู่ (รีจิสเตอร์, program counter, stack pointer) แล้วกู้คืนสถานะของอีกเธรดหนึ่ง เพื่อให้ core เดียวสลับ (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
```

ต้นทุน **ทางตรง** อยู่ที่ไม่กี่ไมโครวินาที ส่วนต้นทุน **ทางอ้อม** — cache และ TLB ที่เย็นลงหลังการสลับ — มักเป็นหมัดที่หนักกว่า: เธรดที่เพิ่งเข้ามาจะทำงานช้าอยู่พักหนึ่งขณะที่มันอุ่น cache กลับคืนจากหน่วยความจำหลัก (หลายสิบถึงหลายร้อย cycle ต่อ miss หนึ่งครั้ง)

## การสลับเธรด vs การสลับโปรเซส

การสลับระหว่าง **เธรดของโปรเซสเดียวกัน** ถูกกว่า: พวกมันแชร์ address space เดียวกัน ดังนั้น page table (และ TLB บนฮาร์ดแวร์ที่ไม่มี tagged TLB / PCID) จึงไม่ต้องเปลี่ยน การสลับ **โปรเซส** ยังต้องโหลดรีจิสเตอร์ฐานของ page table ใหม่ และตามธรรมเนียมคือ flush TLB ด้วย — จึงเป็นเหตุว่าทำไมมันจึงแพงกว่า

## ทำไมมันสำคัญในทางปฏิบัติ

- **เธรดมากเกินไป** → scheduler เกิด thrash ใช้ cycle ไปกับการสลับแทนที่จะทำงาน เลยจุดหนึ่งไป การมีเธรดมากกว่า core จะ *ลด* throughput
- มันเป็นข้อโต้แย้งหลักสำหรับโมเดล **async / event-loop** (Node, nginx, `io_uring`) และ **goroutine / green thread**: จัดการหลายการเชื่อมต่อด้วย OS thread จำนวนน้อย หลีกเลี่ยงการสลับหนึ่งครั้งต่อ request
- มันคือเหตุผลว่าทำไม **CPU pinning / affinity** จึงช่วยเซอร์วิสที่ไวต่อ latency — คงเธรดไว้บน core เดียวเพื่อรักษา cache ที่ยังอุ่นของมัน
- จำนวน context switch แบบไม่สมัครใจ (involuntary) ที่สูง (เห็นได้ใน `vmstat`, `pidstat`) เป็นอาการคลาสสิกของ lock contention หรือการจอง CPU เกิน (oversubscription)

## ทำไมจึงสำคัญ

นี่เป็นคำถามระดับ senior เพราะมันแยกคนที่รู้แค่ *ศัพท์* ออกจากคนที่เข้าใจ *ว่าทำไม* มันถึงแพง — และคำตอบที่แท้จริง (การปนเปื้อน cache/TLB ไม่ใช่แค่การบันทึกรีจิสเตอร์) เป็นตัวขับเคลื่อนการตัดสินใจเชิงสถาปัตยกรรม: async I/O แทน thread-per-request, ปรับขนาด thread pool ให้พอดีกับจำนวน core, และการใช้ affinity มันร้อยเรื่อง scheduling, virtual memory, และ CPU cache เข้าเป็นเรื่องราวประสิทธิภาพเรื่องเดียว

ต้นทุนซ่อนอยู่ที่ไหน

การสลับเธรด vs การสลับโปรเซส

ทำไมมันสำคัญในทางปฏิบัติ

ทำไมจึงสำคัญ

คำถามที่เกี่ยวข้อง