모범답안 — 가상 메모리, 페이지 테이블, TLB

난이도: 중

핵심 답변

가상 메모리: 각 프로세스에 실제 물리 메모리와 분리된 자기만의 연속적인 가상 주소 공간을 주는 기법. OS+MMU(하드웨어)가 가상→물리 변환을 담당한다.
이점: ① 프로세스 간 격리/보호(서로의 메모리를 못 본다), ② 물리적으로 흩어진 프레임을 연속된 것처럼 보이게 함, ③ 실제 RAM보다 큰 주소 공간 사용(스왑/디맨드 페이징), ④ 공유 라이브러리/mmap 등 공유 매핑 가능.
변환 과정: 가상 주소 = [가상 페이지 번호(VPN) | 페이지 내 오프셋]. 페이지 테이블이 VPN→물리 프레임 번호(PFN)로 매핑. 물리 주소 = [PFN | 오프셋]. 페이지/프레임은 매핑의 최소 단위로 보통 4KB.
TLB: 최근 사용한 VPN→PFN 변환을 캐싱하는 작은 하드웨어 캐시. 매 메모리 접근마다 페이지 테이블을 뒤지면 너무 느리므로, TLB 히트로 변환을 빠르게 끝낸다.
TLB 미스: 변환이 TLB에 없으면 페이지 워크(page walk) — 멀티레벨 페이지 테이블을 메모리에서 단계별로 읽어 변환을 찾는다. x86-64는 4단계(또는 5단계)라 미스 한 번에 메모리 접근이 여러 번 발생할 수 있다.

왜 멀티레벨인가: 64비트 주소 공간 전체를 한 장의 평면 페이지 테이블로 표현하면 테이블 자체가 천문학적으로 커진다. 트리(레벨) 구조로 나눠 실제 매핑된 부분만 테이블을 만들어 공간을 절약한다. 대신 변환 시 레벨 수만큼 메모리를 따라 내려가야 한다(x86-64: PML4→PDPT→PD→PT, 4번).
TLB의 효과: 페이지 워크는 4단계면 최대 4번의 메모리 접근(각 ~100ns 가능). TLB가 히트하면 단 1사이클 수준. 그래서 변환 결과를 캐싱하는 TLB의 적중률이 성능을 좌우한다.
TLB도 캐시처럼 동작: 엔트리 수가 제한적(수십~수천). 한 엔트리가 4KB만 커버하므로, 워킹셋이 TLB 커버리지(= 엔트리수 × 페이지크기)를 넘으면 미스가 폭증한다.
컨텍스트 스위칭과 TLB: 프로세스 전환 시 주소 공간이 바뀌면 TLB가 (전부 또는 ASID 미사용 시) 무효화되어 변환을 다시 채워야 한다. 이것이 컨텍스트 스위칭 간접 비용의 일부(문제 2 연계).
huge page: 페이지를 4KB 대신 2MB(또는 1GB) 로 키우면, TLB 엔트리 하나가 더 넓은 영역을 커버 → 같은 워킹셋을 더 적은 엔트리로 덮어 TLB 미스/페이지 워크가 급감하고, 페이지 테이블 레벨도 줄어든다.

시나리오 진단:

수 GB 맵을 무작위 접근 → 접근하는 페이지가 매번 달라 TLB 적중률이 바닥. 대역폭은 한가해 보여도 각 접근이 TLB 미스 → 페이지 워크(추가 메모리 접근)로 지연이 쌓인다. "변환 비용"이 병목이라는 프로파일러 신호와 일치.
개선책:
- huge page(2MB) 도입: TLB 커버리지를 수백 배 늘려 큰 맵의 무작위 접근에서도 미스를 크게 줄인다. Linux는 Transparent Huge Pages(THP) 또는 명시적 hugetlbfs/MADV_HUGEPAGE, Windows는 large-page 할당. 트레이드오프: 메모리 단위가 커져 내부 단편화/메모리 낭비가 늘고, 디맨드 페이징·NUMA 배치가 거칠어지며, THP는 백그라운드 압축으로 지연 스파이크를 만들 수 있다.
- 접근 지역화: 맵을 타일/청크 단위(예: 공간을 격자로 쪼갠 블록)로 묶어 인접 좌표가 같은 페이지에 모이도록 배치 → 한 플레이어 주변 조회가 같은 소수 페이지에 집중되어 TLB·캐시 모두 살아난다.
- 접근 순서 정렬: 배치 처리 시 좌표를 공간 정렬(예: Morton/Z-order curve)해 메모리 순회를 공간적으로 인접하게 만들면 페이지·캐시라인 재사용↑.
- 프리페치/타일 스트리밍: 자주 안 쓰는 영역은 굳이 상주시키지 않고 필요 영역만 올린다(메모리 압박도 완화).

페이지 크기를 캐시라인(64B)과 혼동. 페이지는 보통 4KB, 캐시라인은 64B.
TLB를 "그냥 캐시의 일종"으로 뭉뚱그리고, 주소 변환 전용 캐시라는 점과 미스 시 페이지 워크 비용을 설명 못 함.
가상 메모리를 "스왑(디스크) 기능"과 동일시. 스왑은 가상 메모리가 가능케 하는 한 응용일 뿐, 본질은 주소 변환/격리.
huge page를 "무조건 빠름"으로 단정하고 메모리 낭비·NUMA·THP 스파이크 같은 단점을 놓침.
TLB 미스와 페이지 폴트를 혼동. TLB 미스는 변환이 캐시에 없을 뿐 매핑은 존재(하드웨어 페이지 워크로 해결), 페이지 폴트는 매핑/페이지 자체가 메모리에 없어 OS가 개입(문제 7).

Q. TLB 미스는 누가 처리하나요? A. x86은 하드웨어가 자동으로 페이지 워크를 수행한다(하드웨어 walker). 일부 아키텍처(예: 옛 MIPS)는 소프트웨어가 처리한다. 어느 쪽이든 미스는 추가 메모리 접근을 동반해 비싸다.
Q. 페이지 테이블 자체는 어디에 있나요? A. 물리 메모리에 있고, 각 프로세스마다 별도. CPU의 페이지 테이블 베이스 레지스터(x86의 CR3)가 현재 프로세스의 최상위 테이블을 가리키며, 컨텍스트 스위칭 때 교체된다.
Q. ASID/PCID는 무엇을 해결하나요? A. TLB 엔트리에 주소 공간 식별자를 붙여, 컨텍스트 스위칭 때 TLB를 통째로 비우지 않고 프로세스별로 구분 유지 → 전환 후 TLB 콜드 비용을 줄인다.