커널로 들어가는 순간부터 Page Fault까지

0. 들어가기

운영체제를 보면 용어가 한 번에 등장한다.

• interrupt, system call, exception
• page table, TLB, page fault
• swap, thrashing, working set

이 글은 개념을 나열하기보다, 흐름을 따라가며 정리하는 걸 목표로 한다.

---

1. 커널로 들어가는 사건은 3가지로 묶인다

CPU는 원래 명령어를 순서대로 실행한다.

그런데 어떤 순간에는 실행이 끊기고 커널 코드가 실행된다.

이 사건은 크게 3가지다.

1.1. Hardware Interrupt (외부에서 들어옴)

• 외부 장치/타이머/I/O 완료/입력 같은 이벤트가 원인이다.
• 비동기(asynchronous) 성격이라 현재 코드 흐름과 무관하게 들어올 수 있다.
• interrupt handler가 이를 처리하며, 전통적으로 ISR이라고 부르는 경우가 많다.

1.2. System Call (요청해서 들어감)

• 유저 프로그램이 파일/네트워크 같은 커널 기능을 요청할 때 발생한다.
• 동기(synchronous)이고 의도적인 진입이다.
• syscall(trap) entry로 커널에 들어가 syscall handler가 서비스를 수행한다.

1.3. Exception (터져서 들어감)

• 현재 명령이 정상 수행될 수 없을 때 커널이 개입한다.
• 동기(synchronous)이고 보통 비의도적이다.
• 대표 예시가 page fault다. (+ 0으로 나누기 등)

---

2. 공통 흐름: Save → Enter → Handle → Return

 

세 가지 사건은 커널에 들어갈 때 비슷한 골격을 따른다.

2.1. Step 1) Context Save(문맥 저장)

커널 핸들러로 점프하면 원래 실행 위치를 잃는다.

그래서 복귀에 필요한 정보를 저장한다.

2.1.1. 대표적으로 저장되는 것

• PC/IP: 다음에 실행할 명령 주소(복귀 주소)
• processor state/flags: 인터럽트 enable 등 CPU 상태
• general registers(필요분)

2.1.2. 보강(일반 지식)

• 저장 범위는 CPU/OS 구현에 따라 다를 수 있다.
• 구현상으로는 커널이 통제하는 영역(커널 스택/커널 컨텍스트)에 저장하는 설계가 흔하다.

2.2. Step 2) Handler로 진입(벡터/엔트리 기반)

사건 종류에 맞는 커널 진입점으로 들어간다.

• 하드웨어 인터럽트: interrupt vector → interrupt handler(ISR)
• 예외(page fault 포함): exception vector → exception handler
• 시스템콜: syscall/trap entry로 진입 후 syscall number로 서비스 디스패치

2.3. Step 3) Handler 실행

각 handler가 맡은 일을 수행한다.

2.4. Step 4) Return 또는 Retry

대부분은 문맥 복원 후 원래 코드로 복귀한다.

page fault는 페이지를 올린 뒤, 실패했던 명령을 다시 실행(retry)하는 흐름이 특징이다.

---

3. [예시]: 파일 읽기는 왜 system call인가?

앱에서 파일을 읽을 때 유저 모드에서 디스크/파일 시스템 내부에 직접 접근할 수 없다.

그래서 read 같은 요청은 시스템콜을 통해 커널로 들어간다.

3.1. 흐름

1. 시스템콜로 커널 진입
2. 커널이 권한/유효성 검사
3. 파일 시스템 코드가 I/O 수행
4. 결과 반환

---

4. 가상메모리로 넘어가기 (page fault를 이해하려면)

page fault는 예외의 한 종류이고, 메모리 주소 변환 과정에서 발생한다.

따라서 가상주소가 어떻게 물리주소로 바뀌는지부터 정리해야 한다.

---

5. 가상메모리: 주소는 [VPN | offset]으로 해석된다

페이지 단위로 관리하기 때문에 주소는 이렇게 나뉜다.

5.1. VPN과 offset

• VPN(가상 페이지 번호): 몇 번째 페이지인가
• 페이지테이블이 하는 일은 VPN을 PFN으로 바꾸는 것
• offset은 “그 페이지 안에서의 위치”라서 PFN이 바뀌어도 그대로 붙는다

5.2. 페이지 크기가 4KB라면 (1kb = 1024)

• offset 범위는 0~4095
• VPN = 주소 / 4096, offset = 주소 % 4096 (몫/나머지)

5.3. 페이지와 프레임 offset이 그대로인 이유

페이지/프레임 크기가 같아서 페이지 내부 위치가 유지되기 때문이다.

 

---

6. Page / Frame / Page Table / TLB

6.1. Page와 Frame의 차이

가상메모리에서 Page와 Frame은 “어디를 기준으로 보느냐”가 다르다.

 

• Page(페이지)
  • 프로세스가 보는 가상 메모리를 일정 크기로 나눈 조각
  • “가상 주소 공간에서의 단위”
• Frame(프레임)
  • 실제 물리 메모리(RAM) 를 같은 크기로 나눈 칸
  • “RAM에서의 단위”

 

둘의 관계는 다음처럼 기억하면 된다.

• 페이지는 “가상 메모리 조각”
• 프레임은 “RAM 칸”
• 페이지 하나가 프레임 하나에 올라간다(크기가 같기 때문)

6.2. Page Table

페이지테이블은 매핑/상태표다.

• VPN → PFN(물리 프레임 번호) 매핑
• valid/present(메모리에 있나)
• 권한(R/W/X, user/kernel)

6.3. TLB

주소 변환 결과(VPN→PFN)를 캐시해 둔 버퍼다.

• hit면 바로 변환
• miss면 page table을 조회한다

---

7. TLB miss와 Page Fault

7.1. TLB miss

• 변환 캐시에 없다는 뜻이다.
• page table 조회로 이어진다.
• 이 자체로 RAM에 페이지가 없다고 단정할 수 없다.

7.2. Page fault

page table을 봤더니

• valid=0(= RAM에 없음) 이거나
• 권한 위반이면
• 커널 예외 처리 경로로 진입한다.

---

8. 예시: page fault는 어떤 순간에 터지나?

8.1. 흐름

1. CPU가 메모리 접근 시도
2. TLB miss → page table 조회
3. valid=0 → page fault 발생 → 커널 진입
4. swap-in(필요하면 swap-out)
5. page table/TLB 갱신
6. 실패했던 명령을 retry

---

9. swap과 thrashing

page fault가 “너무 자주” 발생하면 성능 문제가 된다.

9.1. swap-in / swap-out

• RAM에 자리가 있으면 swap-in
• 없으면 victim 선택 → swap-out → swap-in

9.2. thrashing

• page fault 폭증 → swap I/O 대기 증가
• CPU가 계산보다 대기를 더 많이 하게 되는 상태

9.3. working set / PFF

• working set: 최근 Δ 동안 실제로 참조한 페이지 집합
• PFF: page fault 빈도로 프레임을 조절
  • PFF 높음 → 프레임 늘림(또는 부하 조절)
  • PFF 낮음 → 프레임 회수/재분배

---

10. 마무리

 

정리하면서 결국 중요한 건 “용어”가 아니라 흐름이었다.

CPU가 커널로 들어가는 순간을 하드웨어 인터럽트 / 시스템콜 / 예외로 나눠서 보니,

각각이 왜 다르게 동작하는지(비동기 vs 동기)가 한 번에 정리됐다.

 

그리고 가상메모리는 이 흐름 위에 그대로 얹혀 있었다.

TLB miss → page table → (valid=0이면) page fault → swap → retry로 이어지는 한 줄이 잡히니까,

TLB miss와 page fault를 섞어 보던 지점도 자연스럽게 풀렸다.

 

마지막으로 thrashing / working set / PFF는

“메모리가 부족할 때 OS가 어떻게 무너지고, 또 어떻게 버티게 만드는가”를 설명하는 개념이라는 걸 알게 됐다.

 

이제는 새로운 키워드를 외우기보다,

커널 진입 → 주소 변환 → fault 처리 → 성능 붕괴/완화

이 흐름으로 이해를 확장해보려 한다.