TLB
- MMU(Memory Management Unit) 내부의 HW
- 가상 - 실제 주소 변환에 사용되는 하드웨어 캐시
- Page Table을 참조하지 않고도 빠른 속도로 번역 수행

Paging Hardware with TLB

- 6비트의 Logical Address 생성
⠀⠀
- Offset은 그대로, VPN은 TLB에서 주소 변환
⠀⠀
- TLB에 해당 VPN 존재 시
→ TLB Hit → Page Frame Number 반환
⠀⠀
TLB에 해당 VPN 존재하지 않을 시
→ TLB Miss → Page Table로 이동 → VPN에 해당하는 실제 PFN 반환
TLB Entry

- TLB는 Fully-Associative 방식으로 관리된다.
- TLB는 일반적으로 32, 64, 128개의 Entry를 갖는다.
- MMU는 전체 TLB를 병렬로 검색하여 원하는 주소 변환을 찾는다.
- Other Bits: Valid Bits, Protection Bits, Address-Space Identifier, Dirty Bit

Example: Accessing an Array
- TLB의 성능을 증가시키는 방법
→ 공간적 지역성 (Spatial Locality) 사용

- 16개의 Virtual Page, 16바이트의 Page → VPN 4비트, Offset 4비트
⠀⠀
- TLB Hit Rate: 70%
- a[0] : TLB Miss (TLB → VPN 6로 저장)
- a[1] : TLB Hit
- a[2] : TLB Hit
- a[3] : TLB Miss (TLB → VPN 7로 저장)
- a[4] : TLB Hit
- a[5] : TLB Hit
- a[6] : TLB Hit
- a[7] : TLB Miss (TLB → VPN 8로 저장)
- a[8] : TLB Hit
- a[9] : TLB Hit
Effective Access Time (EAT)
- TLB Hit Ratio α: 80%
- TLB Search: 20ns
- Memory Access: 100ns
- EAT = 0.80 (TLB Hit) x (20 (TLB Search) + 100 (Memory Access)) + 0.20 (TLB Miss) x (20 (TLB Search) + 100 (Memory Access) + 100 (Memory Access)) = 140ns
Problem 1: Context Switching

- Process A의 10번 Page 요청 → TLB Miss → Table에 TLB Entry 삽입

- Context Switch → Process B의 10번 Page 요청 → TLB Miss → Table에 TLB Entry 삽입
→ TLB Table 내에서 어떤 프로세스의 Entry인지 구분 불가
Solution 1
- Context Switching이 발생할 때 Valid 필드의 모든 값을 0으로 변경
→ 새 프로세스가 실행될 때 TLB Miss 발생
→ 과도한 비용 소모
Solution 2
- TLB Table 내에 새로운 필드(Address Space Identifier, ASID)를 추가하여 프로세스 구분

Page Sharing

- ASID를 추가하면서 Code 공유가 가능해진다.
- Process 1은 Process 2와 101번 Physical Page를 공유한다.
- Process 1 주소 공간 10번째에 해당 페이지가 존재한다.
- Process 2 주소 공간 50번째에 해당 페이지가 존재한다.
→ 페이지 공유를 통해 실제 메모리 공간을 절약할 수 있다.
TLB Replacement Policy
⠀⠀