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
```

**직접(direct)** 비용은 수 마이크로초다. **간접(indirect)** 비용 — 전환 이후의 차가운 캐시와 TLB — 이 종종 더 큰 타격이다: 새로 들어온 thread는 주 메모리로부터 캐시를 다시 데우는 동안 한동안 느리게 돈다(miss당 수십에서 수백 cycle).

## thread 전환 vs process 전환

**같은 프로세스의 thread 간** 전환이 더 싸다: 주소 공간을 공유하므로 page table(그리고 tagged TLB / PCID가 없는 하드웨어에서는 TLB)이 바뀔 필요가 없다. **process** 전환은 추가로 page-table base register를 다시 로드하고 전통적으로 TLB를 flush한다 — 그래서 비용이 더 든다.

## 실무에서 왜 중요한가

- **너무 많은 thread** → scheduler가 thrash되어 일하는 대신 전환에 cycle을 쓴다. 어느 지점을 넘으면 core 수보다 thread가 많아질수록 throughput이 *줄어든다*.
- 이는 **async / event-loop** 모델(Node, nginx, `io_uring`)과 **goroutine / green thread**를 지지하는 핵심 논거다: 적은 OS thread로 많은 연결을 처리해 request마다 전환이 일어나는 것을 피한다.
- 이것이 **CPU pinning / affinity**가 latency에 민감한 서비스에 도움이 되는 이유다 — thread를 한 core에 붙여 두어 따뜻한 캐시를 보존한다.
- 비자발적(involuntary) context-switch 수가 높은 것(`vmstat`, `pidstat`에서 확인 가능)은 lock contention이나 CPU 초과 할당(oversubscription)의 고전적 증상이다.

## 왜 중요한가

이는 senior 수준의 질문인데, *용어*를 아는 사람과 *왜* 비싼지 이해하는 사람을 가르기 때문이다 — 그리고 진짜 답(register 저장만이 아니라 캐시/TLB 오염)은 아키텍처 결정을 이끈다: thread-per-request 대신 async I/O, thread pool을 core 수에 맞게 산정하기, affinity 사용. 이는 scheduling, 가상 메모리, CPU 캐시를 하나의 성능 이야기로 엮는다.

비용은 어디에 숨어 있는가

thread 전환 vs process 전환

실무에서 왜 중요한가

왜 중요한가

관련 질문