9장 - TLB와 메모리 성능 최적화 (74)

TLB와 메모리 성능 최적화

이전 포스팅에서 페이지 테이블을 통한 주소 변환 과정을 살펴봤습니다. 하지만 이 과정에는 심각한 성능 문제가 있었죠. 바로 하나의 메모리 접근을 위해 두 번의 물리 메모리 접근이 필요하다는 점입니다. 오늘은 이 문제를 해결하는 혁신적인 하드웨어 기술인 TLB(Translation Lookaside Buffer)에 대해 알아보겠습니다.

 

페이지 테이블의 성능 문제

이중 메모리 접근 문제

일반적인 페이징 시스템에서 메모리 접근 과정:

1. 페이지 테이블 접근 (논리 주소 → 물리 주소 변환)
2. 실제 데이터 접근 (변환된 물리 주소로 데이터 읽기/쓰기)

예를 들어, int x = array[100]; 같은 간단한 코드도:

1. 페이지 테이블에서 array의 물리 주소 찾기
2. 실제 물리 메모리에서 데이터 읽기

결과: 메모리 접근 시간이 2배로 증가!

문제의 심각성

• 메모리 접근은 프로그램 실행에서 가장 빈번한 연산
• 성능 저하가 전체 시스템 성능에 직접적 영향
• 특히 메모리 집약적인 프로그램에서 심각한 병목

TLB란 무엇인가?

TLB의 정의

TLB(Translation Lookaside Buffer)는:

• 주소 변환 캐시(Address Translation Cache)
• 최근에 접근한 페이지 번호와 프레임 번호의 쌍을 저장하는 고속 캐시 메모리
• MMU 내부에 위치하는 하드웨어 구조

TLB의 특징

크기: 64~1024개 항목 (매우 작음)
속도: 메인 메모리보다 수십 배 빠름
구조: Content-Addressable Memory (CAM) 또는 Associative Memory
검색 방식: 모든 항목을 동시에 병렬 검색

TLB 항목 구조

[페이지 번호] → [프레임 번호]

예시:
| 페이지 번호 | 프레임 번호 |
|-------------|-------------|
| 5 | 127 |
| 12 | 45 |
| 8 | 203 |
| ... | ... |

TLB를 활용한 메모리 접근 과정

1. TLB Hit (캐시 적중)

1. CPU가 논리 주소 생성
2. 페이지 번호를 TLB로 전송
3. TLB에서 모든 항목 동시 검색
4. 페이지 번호 발견! (TLB Hit)
5. 해당 프레임 번호 즉시 반환
6. 물리 주소 = 프레임 번호 + 옵셋

결과: 메모리 접근 1번으로 완료!

2. TLB Miss (캐시 실패)

1. CPU가 논리 주소 생성
2. 페이지 번호를 TLB로 전송  
3. TLB에서 페이지 번호 발견 못함 (TLB Miss)
4. MMU가 페이지 테이블에서 프레임 번호 조회
5. 물리 주소 = 프레임 번호 + 옵셋
6. 새로운 [페이지 번호, 프레임 번호] 쌍을 TLB에 추가

결과: 기존과 동일한 2번 메모리 접근

실제 성능 향상 사례 분석

C 프로그램 예시

int n[100];  // 400바이트, 전역변수 (페이지 2에 위치)
int sum = 0; // 전역변수
...
for(int i = 0; i < 100; i++)
    sum += n[i];

환경 설정

• 32비트 CPU, 4KB 페이지
• 배열 n[100]의 논리 주소: 0x2000부터 시작 (페이지 2)
• 배열 n[100]의 물리 주소: 0x7000부터 시작 (프레임 7)
• 배열 크기: 400바이트 (한 페이지 내에 모두 포함)

TLB 동작 분석

첫 번째 반복 (i=0):

1. n[0] 접근 → 논리 주소 0x2000
2. 페이지 번호 2를 TLB에서 검색
3. TLB Miss 발생!
4. 페이지 테이블에서 프레임 7 조회
5. 물리 주소 0x7000에서 데이터 읽기
6. TLB에 [페이지2, 프레임7] 저장

메모리 접근: 2번 (페이지 테이블 + 데이터)

두 번째 반복 (i=1):

1. n[1] 접근 → 논리 주소 0x2004
2. 페이지 번호 2를 TLB에서 검색
3. TLB Hit! 프레임 7 즉시 반환
4. 물리 주소 0x7004에서 데이터 읽기

메모리 접근: 1번 (데이터만)

나머지 98번의 반복:

• 모두 동일한 페이지 2에 접근
• 계속해서 TLB Hit 발생
• 각각 1번의 메모리 접근만 필요

성능 향상 계산

TLB 없이: 100번 × 2회 접근 = 200번 메모리 접근
TLB 사용: 1번 × 2회 + 99번 × 1회 = 101번 메모리 접근

성능 향상: 약 98% 감소!

참조의 지역성과 TLB 효율성

공간적 지역성 (Spatial Locality)

연속된 메모리 주소에 접근하는 경향:

// 배열 순차 접근 - TLB Hit 율 높음
for(int i = 0; i < 1000; i++) {
    array[i] = i;
}

시간적 지역성 (Temporal Locality)

최근 접근한 메모리를 다시 접근하는 경향:

// 같은 변수 반복 접근 - TLB Hit 율 높음
int sum = 0;
for(int i = 0; i < 100; i++) {
    sum += i;  // sum 변수 반복 접근
}

TLB 성능에 영향을 주는 요소들

1. 페이지 크기의 영향

큰 페이지 크기의 장점:

• 한 페이지에 더 많은 데이터 포함
• TLB Hit 율 증가
• 성능 향상

큰 페이지 크기의 단점:

• 내부 단편화 증가
• 메모리 낭비

2. TLB Reach (도달 범위)

TLB Reach = TLB 항목 수 × 페이지 크기

예시:

• TLB 항목: 64개
• 페이지 크기: 4KB
• TLB Reach: 64 × 4KB = 256KB

의미: TLB가 가득 찼을 때 미스 없이 접근 가능한 메모리 범위

3. 프로그램 패턴의 영향

TLB 친화적인 패턴:

// 순차 접근 - 좋음
for(int i = 0; i < SIZE; i++) {
    process(array[i]);
}

TLB 비친화적인 패턴:

// 랜덤 접근 - 나쁨
for(int i = 0; i < SIZE; i++) {
    int random_index = rand() % SIZE;
    process(array[random_index]);
}

컨텍스트 스위칭과 TLB

TLB 무효화의 필요성

프로세스가 바뀔 때 TLB를 비워야 하는 이유:

프로세스 A: 페이지 5 → 프레임 100
프로세스 B: 페이지 5 → 프레임 200

같은 페이지 번호가 다른 프레임을 가리킴!

컨텍스트 스위칭 과정

void context_switch(Process* old, Process* new) {
    // 1. 레지스터 저장
    save_registers(old);

    // 2. 페이지 테이블 교체
    set_ptbr(new->page_table_base);

    // 3. TLB 완전 무효화
    flush_tlb();  // 모든 TLB 항목 삭제

    // 4. 레지스터 복원
    restore_registers(new);
}

성능 오버헤드

• TLB 무효화 후 새 프로세스는 TLB Miss부터 시작
• 초기 실행 시 성능 저하 발생
• 시간이 지나면서 TLB가 채워지며 성능 회복

TLB 최적화 기법

1. ASID (Address Space Identifier)

일부 최신 프로세서에서 지원:

• TLB 항목에 프로세스 ID 추가
• 컨텍스트 스위칭 시 TLB 무효화 불필요
• 성능 크게 향상

2. 다단계 TLB

• L1 TLB: 작고 빠름
• L2 TLB: 크고 상대적으로 느림
• 캐시와 유사한 계층 구조

실제 시스템에서의 TLB

현대 프로세서의 TLB 사양

Intel Core i7:

• L1 Data TLB: 64개 항목
• L1 Instruction TLB: 128개 항목
• L2 Shared TLB: 1024개 항목

ARM Cortex-A77:

• L1 TLB: 48개 항목
• L2 TLB: 1280개 항목

마무리

TLB는 페이징 시스템의 성능 문제를 해결하는 핵심 기술입니다. 참조의 지역성을 활용하여 대부분의 메모리 접근에서 페이지 테이블 조회를 생략함으로써 극적인 성능 향상을 제공합니다.

하지만 TLB만으로는 페이징의 모든 문제가 해결되지 않습니다. 다음 포스팅에서는 페이지 테이블 자체의 메모리 낭비 문제와 이를 해결하는 역 페이지 테이블에 대해 알아보겠습니다.

개발자로서 TLB의 특성을 이해하고 TLB 친화적인 코드를 작성한다면, 애플리케이션의 성능을 크게 향상시킬 수 있습니다.