Translation Lookaside Buffer

TLB에 대한 내용은 저번에 Paging에 대한 글에서 살펴보았었죠?

 

TLB는 full associative method를 통해 관리됩니다.

보통 TLB는 32,64,128개 정도의 Entry가 있는데, Hardware가 TLB에서 이 엔트리를 parallel하게 검색하여 줍니다.

 

TLB는 그리고 PFN 이외에도 valid bit, protection bit, ASID(address-space identifier) 등을 또 저장합니다.

이 ASID의 쓰임새는 나중에 알아보도록 하겠습니다.

 

TLB에는 두가지 이슈가 있는데

1) TLB Miss를 누가 Handle할 것인지 (Hardware vs Software) 이고,

2) Context Switch를 어떻게 관리할 것인지 (Flush vs ASID) 입니다.

 

1번 문제에 대해서 먼저 살펴보겠습니다.

 

만약 Hardware가 manage할 경우에 대해 살펴보겠습니다.

• Hardware가 TLB Miss를 처음부터 끝까지 알아서 Control 합니다.
  • Hardware는 두가지 정보를 압니다.
    1. Memory에 저장된 PTE의 Address (page table base register) (PTBR)
    2. Page Table과 PTE의 format
  • Hardware은 Page Table을 "walk" 합니다.
    1. 현재 Page Table로 Jump 합니다
    2. 알맞은 PTE를 찾습니다.
    3. TLB에 들어가기 알맞게 주소를 추출합니다. (Page table translation)
    4. TLB를 업데이트 합니다.
    5. 다시 정보를 Access하여 TLB HIT이 나도록 합니다.

만약 그렇다면 Software가 Manage하면 어떨까요?

실제로도 RISC나 MIPS 구조와 같은 Modern Architecture에서는 TLB Miss를 Operating System에서 관리합니다.

 

1. Hardware가 exception을 띄워 TLB miss가 났다는 것을 알립니다.
   • 현재의 instruction stream을 멈춥니다.
   • Kernel에게 우선순위를 전부 줍니다.
   • Trap handler 로 넘어갑니다.
2. OS내의 Trap handler가 호출된 상황입니다.
3. OS는 page table의 translation을 살펴봅니다.
4. OS가 TLB를 업데이트 하기 위해서 특별한 연산을 수행합니다.
5. OS가 Trap에서 넘어옵니다.
6. 다시 정보를 Access하여 TLB Hit가 나도록 합니다.

각각의 장-단점은 다음과 같습니다.

 

• Hardware-managed TLB
  • (+) Efficient 합니다
  • (–) CPU Design이 복잡해집니다.
  • (–) Page Table의 유연성이 떨어집니다.
  • (–) TLB Miss가 날 가능성이 높습니다. (Hardware가 victim을 Choose하기 때문에)
• Software-managed TLB
  • (+) CPU Design이 간단해집니다.
  • (+) Page Table이 유연해 집니다.
  • (+) TLB Miss가 날 가능성이 낮습니다.
  • (–) 상대적으로 느립니다. ( Not Efficient )

 

이제 두번째 이슈에 대해서 살펴보겠습니다.

 

만약 Process A와 B에서 같은 VPN을 가질 경우 어떤 것을 찾아야 할지 알 수 없습니다.

 

그래서 한가지 방법은 Context Switch가 일어날때 Flush 해주는 것입니다.

• Context Swtich가 일어날때 다음 프로세스를 위해서 전부 Flush 합니다.
  • 간단한 방법은 전부다 0으로 채우는 방법입니다.
• Flush Operation은 언제 발생할까요?
  • Software관점에서 보면 하드웨어가 TLB-flush하는 명령을 제공하면 OS가 이것을 호출합니다.
  • Hardware 입장에서 보면 (PTBR)이 변경될때 CPU가 clean up 해 줍니다.
• Switch마다 발생하는 TLB Miss로 인해서 Overhead가 심해집니다.

그래서 다른 방법인 Identifier (ASID)를 추가하여 이를 확인하는 것입니다. 이 방법이 더 나은 방법입니다.