paging, TLB, page fault는 어떻게 동작하는가?

Question

IT Interview Practice · Accepted Answer

**Paging**과 **segmentation**은 가상 주소 공간을 조직하는 두 가지 방식이다. 현대 시스템은 압도적으로 paging 기반이다(때때로 그 위에 얇은 segmentation 층을 얹기도 한다).

## Paging

가상 메모리와 물리 메모리는 고정 크기의 **page**와 **frame**(보통 4 KB)으로 잘린다. **page table**이 가상 page → 물리 frame으로 매핑한다. 주소는 **page number**(테이블의 인덱스)와 **offset**으로 나뉜다:

```text
 virtual address  =  [ page number | offset ]
                          │            │
              page table[page] = frame │
                          ▼            ▼
 physical address =  [   frame    | offset ]
```

page table은 크기 때문에 **다층(multi-level)**(트리)이거나 해시되며, 하드웨어 **MMU**가 이를 순회(walk)한다.

## TLB: 빠르게 만들기

모든 메모리 접근마다 다층 page table을 순회한다면 시스템이 마비될 것이다. **TLB(Translation Lookaside Buffer)**는 CPU 안에 있는, 최근의 가상→물리 변환을 담는 작고 빠른 캐시다:

```text
CPU needs addr → TLB hit?  ── yes ──▶ get frame immediately (~1 cycle)
                    │
                    └── no (TLB miss) → walk the page table, fill the TLB (slower)
```

TLB hit 비율은 보통 99%를 넘는다. miss는 비싸며, 그래서 **spatial locality**(공간적 지역성)와 **huge page**(2 MB — 같은 양의 RAM을 덮는 데 필요한 엔트리가 더 적음) 같은 기능이 성능에 중요하다.

## Page fault

page-table 엔트리가 그 page가 **RAM에 없다**고 하면(또는 보호 비트가 위반되면), MMU가 **page fault** trap을 일으킨다. OS가 이를 처리한다: 디스크에서 page 로드(*major* fault), 새 page를 0으로 채우기, 또는 copy-on-write. 디스크에 닿는 page fault는 수백만 cycle이 들므로 — working set을 RAM에 유지하는 것이 중요하다.

## Segmentation

**Segmentation**은 메모리를 **논리 단위** — code, data, stack — 로 나눠 **가변 크기** 세그먼트로 만들고 `[segment selector | offset]`로 주소를 지정한다. 프로그램 구조에 자연스럽게 대응되지만 **외부 단편화(external fragmentation)**(가변 크기의 구멍)를 겪는다. 순수 segmentation은 대체로 역사 속 유물이다. x86은 흔적 형태를 남겨 두었지만, Linux는 이를 평탄화하고 paging에 의존한다.

## 왜 중요한가

paging, TLB, page fault는 "가상 메모리"가 실제 성능과 만나는 지점이다. 면접관은 당신이 추상을 하드웨어 비용과 연결하는지 확인하려고 이를 활용한다: 왜 huge page가 TLB miss를 줄이는지, 왜 page-fault 폭풍이 latency를 무너뜨리는지, 왜 캐시/TLB 친화적 접근 패턴이 빠르게 도는지. 이는 memory-mapped 파일, copy-on-write, thrashing을 위한 필수 배경 지식이기도 하다.

Paging

TLB: 빠르게 만들기

Page fault

Segmentation

왜 중요한가

관련 질문