TLB로 보는 가상 주소 변환과 메모리 접근 성능

페이지 테이블을 매번 따라가면 생기는 비용

가상 메모리에서 CPU는 가상 주소를 물리 주소로 바꾼 뒤에야 실제 데이터에 접근할 수 있다. 이 변환을 매번 페이지 테이블에서 찾으면 페이지 테이블 조회와 데이터 접근이 이어져 메모리 접근 횟수가 두 배로 증가한다.

TLB(Translation Lookaside Buffer)는 최근 사용한 가상 주소-물리 주소 매핑을 보관해 이 경로를 줄이는 고속 하드웨어 버퍼다. 가상 페이지 번호와 물리 페이지 번호의 대응을 TLB에서 찾으면 페이지 테이블 접근 없이 곧바로 물리 주소를 만들 수 있다. 연관 메모리를 사용하므로 여러 엔트리를 병렬로 검색한다.

⤢✕

매핑과 상태를 함께 담는 TLB 엔트리

TLB 엔트리의 검색 키는 가상 페이지 번호(VPN)이고, 검색 결과는 물리 페이지 번호(PPN)다. 여기에 엔트리 유효성을 표시하는 Valid 비트, 읽기·쓰기·실행 권한을 위한 Protection 비트, 수정 여부를 나타내는 Dirty 비트, 접근 여부를 기록하는 Reference 비트가 붙는다.

모든 엔트리를 동시에 비교하는 병렬 검색이 가능한 대신, 용량은 일반 메모리보다 작다. 일반적으로 64~1024 엔트리를 둔다.

⤢✕

히트와 미스에서 달라지는 메모리 경로

TLB 히트에서는 CPU가 가상 주소에서 가상 페이지 번호를 꺼내 TLB를 병렬 검색한다. Valid=1인 일치 엔트리를 찾으면 물리 페이지 번호와 오프셋을 결합해 물리 주소를 만들고, 메모리 접근은 1회로 끝난다. 페이지 테이블 조회를 생략하므로 약 50~90%의 성능 향상을 기대할 수 있다.

반대로 TLB 미스가 나면 페이지 테이블을 메모리에서 조회해 물리 페이지 번호를 얻고, 교체 알고리즘으로 새 엔트리를 TLB에 넣은 뒤 실제 데이터에 접근한다. 페이지 테이블과 실제 데이터를 각각 읽으므로 메모리 접근은 2회다. 해당 페이지가 메모리에 없으면 페이지 폴트 처리와 디스크 I/O가 추가될 수 있다.

⤢✕

교체와 무효화는 캐시의 일관성을 지킨다

공간이 부족한 TLB는 기존 엔트리를 교체해야 한다. LRU(Least Recently Used)는 가장 오래 사용하지 않은 엔트리를 내보내 시간적 지역성을 활용하지만, 하드웨어 카운터가 필요해 구현 복잡도가 높다. Random은 무작위 선택으로 구현이 단순하지만 성능 예측이 어렵다. FIFO(First In First Out)는 먼저 들어온 엔트리를 큐 구조로 교체하며, 최적 성능을 보장하지 않는다. NRU(Not Recently Used)는 참조 비트를 이용해 LRU를 근사한다.

페이지 매핑이나 보호 권한이 바뀌면 TLB의 오래된 매핑도 무효화해야 한다. 전체 플러시는 컨텍스트 스위칭 때 모든 엔트리를 무효화하는 방식이며, 간단하지만 성능 저하가 크고 임베디드 시스템에서 주로 사용된다. 선택적 플러시는 ASID(Address Space Identifier) 태그를 이용해 특정 프로세스의 엔트리만 무효화한다. 페이지 보호 권한 변경이나 메모리 매핑 해제처럼 특정 페이지에만 변화가 생긴 경우에는 해당 엔트리만 삭제할 수 있다.

⤢✕

EAT는 히트율에 민감하다

유효 메모리 접근 시간(EAT)은 TLB 접근과 미스 시 페이지 테이블 조회, 실제 메모리 접근의 비용을 함께 반영한다.

EAT = (TLB Hit Rate × TLB Access Time) + (TLB Miss Rate × Page Table Access Time) + Memory Access Time

TLB 접근 시간이 1 ns, 메모리 접근 시간이 100 ns, TLB 히트율이 95%인 경우를 보자.

TLB Hit: 1ns + 100ns = 101ns
TLB Miss: 1ns + 100ns (페이지 테이블) + 100ns (데이터) = 201ns
EAT = 0.95 × 101ns + 0.05 × 201ns = 95.95ns + 10.05ns = 106ns

TLB가 없으면 200ns가 걸리며, 이 조건에서는 약 47% 빠르다.

히트율은 엔트리 수, 페이지 크기, 워킹 셋, 지역성의 영향을 받는다. 엔트리 수가 늘면 히트율이 높아질 수 있지만 비용과 전력 소비도 증가한다. 일반적인 TLB는 64~1024 엔트리를 사용한다. 큰 페이지는 엔트리 하나가 담당하는 주소 범위를 넓히며, 표준 페이지는 4KB이고 Huge Page는 2MB/1GB다.

프로그램의 워킹 셋이 TLB 크기보다 작으면 높은 히트율을 기대할 수 있지만, 워킹 셋이 TLB보다 훨씬 크면 TLB 스래싱으로 히트율이 떨어진다. 최근 접근한 페이지를 다시 찾는 시간적 지역성과 인접 페이지에 접근하는 공간적 지역성도 이 차이를 좌우한다.

⤢✕

계층형 TLB와 큰 페이지의 선택

다중 레벨 TLB에서는 L1 TLB가 작고 빠른 경로를 맡고, L1 미스 때 L2 TLB를 확인한 후 페이지 테이블로 넘어간다. L1 TLB는 816 엔트리로 명령어와 데이터를 분리하며, L2 TLB는 5121024 엔트리를 통합해 보관한다. 이 계층은 빠른 응답과 높은 히트율 사이의 균형을 맞춘다.

Huge Pages는 표준 4KB 페이지 대신 2MB/1GB 페이지를 써서 TLB 엔트리당 주소 커버 범위를 확대하고 페이지 테이블 크기를 줄인다. 대용량 버퍼 풀을 쓰는 데이터베이스, 게스트 메모리를 다루는 가상화, 대규모 배열 연산을 수행하는 고성능 컴퓨팅이 적용 대상이다. 다만 내부 단편화가 커지고, 페이지 폴트 처리 시간과 메모리 할당 유연성에 부담이 생긴다.

프로세스 식별자를 붙여 캐시를 유지하는 방식

ARM의 ASID는 TLB 엔트리에 프로세스 식별자를 추가한다. 따라서 컨텍스트 스위칭 때 TLB 전체를 플러시하지 않고 여러 프로세스의 매핑을 함께 보관할 수 있다.

x86의 PCID(Process-Context Identifier)는 CR3 레지스터에 12비트 PCID를 포함하고 TLB 엔트리에 PCID 태그를 둔다. 4096개 프로세스를 식별할 수 있다.

⤢✕

프로세서와 워크로드에서 나타나는 차이

Intel Skylake는 L1 ITLB에 명령어용 128 엔트리, L1 DTLB에 데이터용 64 엔트리, 통합 L2 STLB에 1536 엔트리를 둔다. PCID를 지원하며 4096 컨텍스트를 다룬다.

AMD Zen 3는 L1 ITLB와 L1 DTLB에 각각 64 엔트리, L2 TLB에 2048 엔트리를 제공하고 1GB Huge Page를 지원한다. Cortex-A76은 L1 ITLB와 L1 DTLB에 각각 48 엔트리, L2 TLB에 1024 엔트리, 16비트 ASID를 사용한다.

시스템	TLB 히트율	성능 향상
웹 서버	99%	1.5배
데이터베이스 (4KB 페이지)	85%	1.3배
데이터베이스 (2MB Huge Page)	99.5%	1.8배
과학 계산	95%	1.4배

TLB는 페이지 테이블 접근을 캐시해 메모리 접근 횟수를 절반으로 줄이고, 높은 히트율에서 약 50~90%의 성능 향상을 제공한다. 페이지 크기와 메모리 접근 패턴을 선택할 때는 워킹 셋과 지역성, 그리고 플러시 비용까지 함께 고려해야 한다.