이 문서는 의문을 가지고 있던 지점을 AI 에이전트와 대화하며 정리한 메모입니다. 가상 주소가 물리 주소로 변환되는 흐름을 기준으로 MMU, TLB, 페이지 테이블, page fault를 정리합니다.
가상 주소는 어떻게 물리 주소가 될까?#
TLB / MMU / OS 메모리 관리자 (MMS)
목차#
1. MMU와 TLB의 역할과 차이#
큰 그림 — 하드웨어 구조#
CPU
┌─────────────────────────────────────┐
│ ALU / Register / Control Unit │
│ │
│ ┌─────────────────────────────┐ │
│ │ MMU │ │
│ │ ┌───────────────────────┐ │ │
│ │ │ TLB (번역 캐시) │ │ │
│ │ └───────────────────────┘ │ │
│ │ 페이지 테이블 워크 로직 │ │
│ └─────────────────────────────┘ │
│ │
│ ┌───────────────┐ │
│ │ L1/L2 Cache │ │
│ └───────────────┘ │
└──────────────┬──────────────────────┘
│ 물리 주소
▼
[ RAM (DRAM) ]MMU는 CPU 쪽의 하드웨어 주소 변환 유닛이다.
설명 편의상 “CPU와 메모리 사이"라고 말하곤 하지만, 실제로는 CPU에 통합된 주소 변환 하드웨어로 이해하는 편이 가깝다.
TLB는 그 안에서 최근 번역 결과를 캐싱하는 작은 하드웨어 캐시다.
2. 페이징 시스템과 페이지 테이블의 문제#
페이지 크기를 작게 하면?#
비연속적인 메모리 할당 정책에서 페이징 시스템을 사용할 때,
페이지 크기를 작게 하면 내부 단편화는 줄어들지만 페이지 테이블이 거대해지는 문제가 발생한다.
계산 예시#
아래는 32bit 주소 공간, 4KB 페이지, 엔트리 4byte, 단일 레벨 페이지 테이블을 단순 가정한 계산이다.
32bit 주소 공간, 4KB 페이지 기준
→ 페이지 수 = 2^32 / 2^12 = 2^20 = 약 100만 개 엔트리
→ 엔트리당 4byte → 페이지 테이블 하나 = 4MB
→ 프로세스 100개 = 400MB가 페이지 테이블만으로 소비현대 시스템은 주소 공간이 더 크고, 실제로는 사용하지 않는 구간도 많다.
그래서 계층형(다단계) 페이지 테이블을 사용해 페이지 테이블 메모리 낭비를 줄인다.
성능 문제 — page table walk 비용#
페이지 테이블 자체는 메모리에 있다.
따라서 TLB miss가 나면 MMU는 page table walk를 수행해 필요한 엔트리를 읽어 와야 한다.
- 단일 레벨 테이블만 가정하면 “페이지 테이블 1번 + 실제 데이터 1번"처럼 설명할 수 있다.
- 하지만 현대 CPU는 다단계 페이지 테이블을 쓰므로, TLB miss 시 추가 메모리 참조가 더 필요할 수 있다.
- 실제 비용은 CPU cache, page walk cache 유무에 따라 달라진다.
즉, 핵심은 “메모리 접근이 항상 정확히 2배” 가 아니라
“TLB miss가 비싸고, 그래서 번역 캐시가 중요하다” 는 점이다.
3. TLB (Translation Lookaside Buffer)#
역할#
최근에 사용된 가상 주소 → 물리 주소 변환 결과를 캐싱하는 하드웨어 캐시.
동작 흐름#
CPU가 가상 주소 생성
│
▼
┌───────────┐
│ TLB 조회 │──── TLB Hit ──→ 물리 주소 즉시 반환
└───────────┘
│ TLB Miss
▼
MMU가 Page Table Walk
(메모리에 있는 페이지 테이블 순회)
│
▼
물리 주소 획득 → TLB에 저장 → 반환TLB 특징#
| 항목 | 내용 |
|---|---|
| 저장 대상 | 최근에 사용된 가상 주소 → 물리 주소 변환 결과 |
| 위치 | MMU가 활용하는 작은 하드웨어 번역 캐시 |
| 크기/구조 | 구현 의존. 일반적으로 매우 작고 빠름 |
| 효과 | page table walk를 줄여 주소 변환 지연을 낮춤 |
구현에 따라 instruction TLB / data TLB 가 분리되거나,
여러 단계의 TLB가 존재할 수도 있다.
TLB가 효과적인 이유#
시간적 지역성 + 공간적 지역성 덕분이다.
같은 페이지나 인접 페이지를 반복해서 접근하는 패턴이 많기 때문에,
아주 작은 번역 캐시만으로도 page table walk를 크게 줄일 수 있다.
4. Context Switch시 TLB는?#
프로세스나 주소 공간이 바뀌면, 기존 TLB 엔트리를 그대로 쓰면 안 되는 상황이 생긴다.
다만 이때 항상 전체 TLB를 flush해야 하는 것은 아니다.
처리 방식 두 가지#
| 방식 | 설명 | 단점 |
|---|---|---|
| TLB Flush | 주소 공간 전환 시 관련 엔트리를 비움 | 전환 직후 TLB miss가 늘어남 |
| ASID (Address Space ID) | TLB 엔트리에 주소 공간 식별자를 태깅 | 식별자 수와 관리 정책 제약이 있음 |
즉, 주소 공간 전환 = 무조건 전체 TLB 초기화로 외우기보다,
아키텍처가 주소 공간 식별자를 지원하느냐에 따라 flush 전략이 달라진다고 이해하는 편이 정확하다.
5. MMU vs TLB 한 줄 정리#
| MMU | TLB | |
|---|---|---|
| 역할 | 주소 변환 전체 담당 | 자주 쓰는 변환 결과 캐싱 |
| 위치 | CPU의 주소 변환 하드웨어 | MMU가 활용하는 번역 캐시 |
| 구현 성격 | table walk, 권한 검사, fault 발생 등 포함 | 구현 의존적인 작은 온칩 캐시 |
| 없으면 | 가상 주소를 물리 주소로 자동 변환하기 어려움 | page table walk 비용이 커져 성능 저하 |
결론: MMU는 주소 변환이라는 기능 전체를 담당하는 유닛이고,
TLB는 그 안에서 성능 병목을 해결하기 위해 존재하는 캐시 컴포넌트이다.
TLB는 MMU의 일부로 이해하면 된다.
6. OS 메모리 관리자 (MMS)#
표준 용어 정리#
“MMS"는 Linux/Windows 공식 문서에서 대표 표준 약어로 널리 쓰인다기보다,
문맥상 OS의 메모리 관리 서브시스템 정도를 가리키는 표현으로 이해하는 편이 안전하다.
- Linux는 보통 Memory Management (MM) 또는 VM subsystem 맥락으로 설명한다.
- Windows는 Memory Manager 라는 명칭을 쓴다.
하드웨어 vs 소프트웨어 메모리 관리 구분#
[ 프로세스 ] → 가상 주소 생성
│
▼
[ MMU / TLB ] ← 하드웨어
주소 변환 담당
│
│ Page Fault 발생 시 예외
▼
[ OS 메모리 관리자 ] ← 소프트웨어, 커널 내부
페이지 테이블 관리, 페이지 교체, 스왑, fault 처리 담당
│
▼
[ 물리 메모리 (RAM) + 스왑 영역 (Disk) ]OS 메모리 관리자가 하는 일#
1. 페이지 테이블 생성 및 관리#
- 프로세스별 주소 공간에 맞춰 페이지 테이블을 만들고 유지한다.
- 일반적인 범용 OS에서는 OS나 하이퍼바이저가 테이블을 관리하고, MMU는 그 결과를 사용해 번역을 수행한다.
2. Page Fault 처리#
- MMU가 비상주 페이지, 접근 권한 위반 같은 조건에서 page fault 예외를 발생시킬 수 있다.
- OS는 그 원인을 보고 페이지를 적재하거나, 권한 오류라면 예외를 전달하거나 프로세스를 종료한다.
- 정상적인 경우에는 페이지 테이블을 갱신한 뒤 명령을 재실행하게 만든다.
3. 스왑(Swap) 관리#
- 물리 메모리가 부족하면 어떤 페이지를 디스크로 내보낼지 결정한다.
- 페이지 교체 알고리즘을 사용해 메모리 압박을 완화한다.
- 이 부분은 성능에 큰 영향을 주는 운영체제 정책 영역이다.
4. 메모리 할당 (malloc, mmap) 뒤편#
- 사용자 프로그램이 메모리를 요청했을 때, 커널은 가상 주소 공간을 잡고 매핑 정책을 정한다.
- 실제 물리 프레임 할당은 첫 접근 시점까지 미뤄질 수 있다. 이것이 demand paging 맥락이다.
5. 공유 메모리 / Copy-on-Write (CoW)#
fork()같은 동작에서는 처음부터 모든 페이지를 복사하지 않고 공유할 수 있다.- 이후 어느 한쪽이 쓰기를 시도할 때만 복사해서 메모리 낭비를 줄인다.
OS별 메모리 관리자 명칭#
| OS | 메모리 관리자 명칭 |
|---|---|
| Linux | MM subsystem / VM subsystem (mm/) |
| Windows | Memory Manager (Mm, MmXxx 함수군) |
Linux 커널 소스의
mm/디렉터리에는page_alloc.c,swapfile.c,mmap.c같은 코드가 들어 있다.
MMU vs OS 메모리 관리자 비교#
| MMU | OS 메모리 관리자 | |
|---|---|---|
| 종류 | 하드웨어 | 소프트웨어 (커널) |
| 역할 | 주소 변환 실행, 권한 검사, fault 신호 | 변환 규칙(페이지 테이블) 생성, 교체/스왑 정책 결정, fault 처리 |
| 시간 특성 | 메모리 접근 경로의 매우 빠른 하드웨어 처리 | fault 발생 시 훨씬 무거운 커널 처리 |
| 비유 | 통역사 | 통역사에게 사전과 규칙을 제공하는 사람 |
핵심 요약:
MMU는 메커니즘(Mechanism) 을 담당하고,
OS 메모리 관리자는 정책(Policy) 을 담당한다.
참고 자료#
- Arm Learn the Architecture - Memory management: https://developer.arm.com/-/media/Arm%20Developer%20Community/PDF/Learn%20the%20Architecture/LearnTheArchitecture-MemoryManagement-101811_0100_00_en.pdf
- Linux Kernel Documentation - Page Tables: https://docs.kernel.org/6.9/mm/page_tables.html
- Linux Kernel Documentation - Cache and TLB Flushing Under Linux: https://www.kernel.org/doc/html/latest/core-api/cachetlb.html
- Intel - Machine Check Error Avoidance on Page Size Change: https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/machine-check-error-avoidance-on-page-size-change.html
- Microsoft Learn - Windows kernel-mode memory manager: https://learn.microsoft.com/en-us/windows-hardware/drivers/kernel/windows-kernel-mode-memory-manager