#07 PCB & Context Switching

PCB & Context Switching — 프로세스 정보는 어디에 저장돼?

지금까지 인터럽트 글이랑 시스템 콜 글에서 "현재 상태를 저장한다", "컨텍스트 스위칭이 일어난다"는 말이 계속 나왔어. 근데 정확히 어디에 저장하는 건지, 어떻게 복원하는 건지는 안 다뤘거든. 이번에 제대로 파보자.

---

PCB (Process Control Block)

프로세스 하나당 PCB 하나가 만들어져. 프로세스에 관한 모든 정보를 저장하는 자료구조야. 주기억장치(RAM)에 올라가 있고, OS 커널이 관리해.

CPU가 프로세스 A를 실행하다가 B로 전환할 때 A의 현재 상태를 어딘가에 저장해야 나중에 A를 이어서 실행할 수 있어. 그 "어딘가"가 PCB야.

각 필드가 왜 필요한지 포인트만 짚어보자.

• 프로세스 식별자(PID) — 프로세스마다 고유 번호야. OS가 "어떤 프로세스의 PCB인지" 구분하는 데 써.
• 프로그램 카운터(PC) — 다음에 실행할 명령어의 주소야. 컨텍스트 스위칭 후 복귀할 때 이 주소에서 이어서 실행해. OS 글 첫 번째 파트에서 다뤘던 그 PC 레지스터야.
• CPU 레지스터 값 — 스위칭 시점의 레지스터 상태를 전부 저장해. 복원할 때 여기서 로드해서 CPU 상태를 복구해.
• 프로세스 상태 — 현재 ready / running / waiting 중 어떤 상태인지 저장해. 스케줄러가 이 정보로 다음에 실행할 프로세스를 골라.
• CPU 스케줄링 정보 — 우선순위, 최종 실행 시각, CPU 점유 시간. CPU 스케줄링 파트에서 나온 Priority Scheduling이 이 정보를 기반으로 동작해.

PCB는 프로세스의 "주민등록증" 같은 거야. OS가 수십 개의 프로세스를 관리할 때 각 프로세스 정보를 어딘가에 기록해둬야 하는데, 그게 PCB야. 프로세스 테이블에 모든 PCB가 모여있고 OS가 필요할 때 꺼내 씀.

 

면접 포인트 ( •̀ ω •́ )✧

Q. PCB란?

프로세스 하나당 생성되는 자료구조로 프로세스의 모든 정보(PID, 상태, PC, 레지스터, 스케줄링 정보 등)를 저장해. 커널이 관리하며 주기억장치에 저장돼. 컨텍스트 스위칭 시 상태 저장과 복원에 사용해.

---

프로세스 상태

프로세스는 실행 중에 여러 상태를 오가. 이 상태들이 PCB의 "프로세스 상태" 필드에 저장돼.

new — 프로세스가 막 생성된 상태야. 아직 실행 준비가 안 됐어. admitted되면 ready로 넘어가.

ready — 실행 준비는 다 됐는데 CPU를 아직 못 받은 상태야. 스케줄러(scheduler)가 이 중에서 하나를 골라 디스패치(dispatch)해서 CPU에 할당해. Ready Queue에서 대기하고 있어.

스케줄러(scheduler): 프로세스들 중에 하나를 고르는 것
디스패치(dispatch): 고른 프로세스를 CPU에 할당하는 것

running — CPU를 실제로 점유해서 실행 중인 상태야. 한 번에 하나의 프로세스만 running 상태일 수 있어 (CPU 코어 기준). 인터럽트가 발생하면 다시 ready 상태로 돌아가.

waiting — I/O나 이벤트를 기다리는 상태야. CPU를 내려놓고 대기해. 파일을 다운로드하는 중에 "허용하시겠습니까?" 팝업을 기다리는 상황을 생각하면 돼 — 다운로드 중이 running, 사용자 허용 기다리는 게 waiting이야. I/O가 완료되면 다시 ready 상태로 돌아가.

terminated — 실행이 완료되거나 강제 종료된 상태야. new랑 terminated는 임시 상태야. 프로세스가 살아있는 동안은 ready ↔ running ↔ waiting을 반복해.

 

면접 포인트 ( •̀ ω •́ )✧

Q. 프로세스의 5가지 상태는?

new(생성), ready(CPU 대기), running(실행 중), waiting(I/O 등 이벤트 대기), terminated(종료). 실제로 프로세스가 살아있는 동안은 ready ↔ running ↔ waiting을 반복해.

---

Context Switching (문맥 교환)

CPU가 현재 실행 중인 프로세스의 상태를 PCB에 저장하고, 다음 실행할 프로세스의 상태를 PCB에서 읽어서 CPU에 적재하는 과정이야.

흐름을 따라가 보자.

1. P1 실행 중 인터럽트 또는 시스템 콜 발생
2. P1의 현재 상태(PC, 레지스터, 프로세스 상태 등)를 PCB1에 저장
3. P1은 idle 상태로 대기
4. 스케줄러가 P2를 선택 → PCB2에서 P2 상태를 로드해서 CPU에 적재
5. P2 실행
6. P2에서 인터럽트 또는 시스템 콜 발생 → P2 상태를 PCB2에 저장
7. PCB1에서 P1 상태 복원 → P1이 멈췄던 위치에서 이어서 실행

여기서 핵심이 하나 있어 — 다이어그램에서 노란색으로 표시한 OS 커널 작업 구간이 바로 "아무 프로세스도 실행 안 되는 시간"이야. idle이라고 표시된 구간. 이 시간 동안 CPU는 실제 작업을 못 해. 이게 Context Switching의 오버헤드야.

---

Context Switching이 발생하는 원인

원본에서 "선점형 스케줄링 때문"이라고만 설명했는데, 원인이 더 있어.

• 타이머 인터럽트 — Round Robin에서 Time Quantum이 만료되면 발생. 가장 흔한 케이스야
• 우선순위 선점 — 더 높은 우선순위 프로세스가 Ready Queue에 들어오면 현재 프로세스를 밀어내
• I/O 또는 이벤트 대기 — 실행 중인 프로세스가 I/O를 요청하면 waiting 상태로 가면서 스위칭 발생
• 시스템 콜 — 커널 모드로 전환하면서 스케줄러가 다른 프로세스를 선택할 수 있어

---

Context Switching 비용

스위칭이 일어나는 동안 CPU는 실제 작업을 못 해. 순수한 오버헤드야. 비용이 발생하는 이유는 세 가지야.

캐시 초기화 — 프로세스가 바뀌면 CPU 캐시에 올라있던 이전 프로세스 데이터가 의미없어져. 새 프로세스에 맞는 데이터로 캐시가 다시 채워져야 해 (Cold Cache 문제).

메모리 매핑 초기화 — 각 프로세스는 독립적인 가상 메모리 공간을 가져. 프로세스가 바뀌면 TLB(Translation Lookaside Buffer)를 비워야 해. 인터럽트 파트에서 다뤘던 내용이야.

커널 실행 — 상태 저장, 스케줄러 실행, 상태 복원 자체가 CPU 시간을 써.

프로세스 vs 스레드 스위칭 비용 차이

스위칭이 잦으면 성능이 떨어지는 문제를 줄이는 방법이 있어. 단일 프로세스 안에서 여러 스레드로 나누는 거야.

프로세스 A → 프로세스 B 스위칭
  - 메모리 공간 다름 → TLB 플러시 필요
  - 캐시 전부 무효화
  - 비용 큼

스레드 1 → 스레드 2 스위칭 (같은 프로세스 내)
  - 메모리 공간 공유 → TLB 그대로
  - 스택만 교체하면 됨
  - 비용 작음

스레드는 같은 프로세스 안에서 Code, Data, Heap을 공유하기 때문에 메모리 공간 전환이 없어. 스택만 바꾸면 돼서 훨씬 가벼워.

 

 

면접 포인트 ( •̀ ω •́ )✧

Q. Context Switching이란?

CPU가 현재 실행 중인 프로세스의 상태를 PCB에 저장하고, 다음 프로세스의 상태를 PCB에서 읽어 CPU에 적재하는 과정이야. 스위칭 중에는 CPU가 실제 작업을 못 하는 오버헤드가 발생해.

Q. Context Switching이 발생하는 원인은?

타이머 인터럽트(Time Quantum 만료), 우선순위 선점, I/O 대기, 시스템 콜 등이 트리거가 돼. 선점형 스케줄링 방식에서 주로 발생해.

Q. 프로세스 Context Switching 비용을 줄이는 방법은?

단일 프로세스 내 멀티 스레드를 사용하면 돼. 스레드는 메모리 공간을 공유하기 때문에 TLB 플러시나 캐시 재초기화가 없어. 스택만 교체하면 돼서 프로세스 스위칭보다 비용이 훨씬 작아.

---

이 글에서 제일 중요한 포인트 두 개만 짚으면 — PCB의 PC 필드랑 idle 구간이야.

PC 필드가 없으면 복귀할 위치를 모르고, idle 구간이 쌓이면 실제 작업보다 전환하는 데 CPU를 더 쓰게 돼. 면접에서 "Context Switching 비용이 왜 생기냐"는 질문 받으면 이 idle 구간과 TLB 플러시를 같이 설명할 수 있으면 돼.