[운영체제] 17. Paging - TLB

Reference - Operating Systems: Three Easy Pieces

 

 

https://pages.cs.wisc.edu/~remzi/OSTEP/

Operating Systems: Three Easy Pieces

 

 

Translation Lookaside Buffers (TLB)

 

TLB는 Paging에서 문제가 됐던 잦은 메모리 접근을 보완하기 위한 방법이다.

자주 사용하는 Page Table Entry의 경우 MMU의 SRAM에 캐싱하는 것이다.

 

기존 Paging은 아래와 같은 방법으로 진행되었다.

 

TLB를 사용하면 Address translation 과정이 이렇게 바뀌게 된다. (PTEA=PTE Address)

캐싱을 한 뒤, 주소 변환을 할 때 TLB부터 조회한 후 원하는 변환 정보가 있으면 바로 전환한다. (위 그림, TLB Hit) 

TLB를 갔는데 원하는 정보가 없으면(TLB Miss), 메모리의 page table에 접근하여 주소 변환 정보를 TLB에 저장한뒤 주소 변환을 시도한다.

이때 성능 향상을 위해 중요한 것은 1. page에 처음 접근할 땐 항상 메모리 접근이 필요하며 2. TLB에 주소가 없는 상황을 최대한 줄여야 한다는 것이다.

 

TLB Miss는 생각보다 자주 발생하지 않는데, 그 이유는 data의 Locality 때문이다.

 

위와 같은 for loop이 있을 때, 데이터가 Time, Spatial Locality 특성으로 연속적이기 때문에 a[0], a[3], a[7]에 접근할때만 Miss가 발생한다. 위 예시는 Page size가 16bytes인 경우이고, 실제 Page size는 4KB이기에 TLB hit ratio가 훨씬 올라간다.

 

 TLB는 full associative method로 관리된다. 즉, 주소 변환 정보는 TLB 내 어디에나 존재할 수 있으며, 하드웨어는 원하는 translation을 찾기 위해 TLB를 병렬로 탐색하여 이를 찾을 수 있다.

 

그렇다면 TLB Miss의 경우 어떻게 Handling해야 할까?

먼저 이는 Hardware-managed와 Software-managed로 나뉜다.

하드웨어(=cpu)가 관리할경우 miss가 발생하면 하드웨어가 page table을 walk해서 TLB로 업데이트하고 주소 변환을 다시 시도한다. 

 

소프트웨어(=OS)가 관리할 경우 hardware가 exception을 발생시키면, OS의 trap handler가 실행되고, page table을 조회하여 TLB를 업데이트하고 주소 변환을 다시 시도한다. 중요한 것은 trap 시 프로세스를 종료하는게 아니라 TLB를 업데이트 한 뒤 다시 실행해야 무한루프를 방지할 수 있다.

 

위 둘을 비교하면, Hardware의 경우 효율적이지만 CPU design이 복잡해지고 유연성이 떨어지며 TLB miss ratio가 올라갈 수 있다. software의 경우 Hardware랑 반대로 생각하면 되며, trap을 발생시키는데 CPU cycle이 많이 필요할 수 있어 반응성이 떨어지기에 비효율적이다.

 

또다른 이슈는 Context switching이다.

두 프로세스는 각자의 va를 가지기에 VPN이 같지만 PFN은 다를 수 있는데, 이 경우 TLB에 같은 VPN을 가진 두 값이 어떤 프로세스의 것인지 구별할 수 없어, Context switch가 발생하면 다른 물리 공간을 매핑할 수도 있다는 문제가 발생한다.

이 문제를 해결하기 위한 첫번째 방법은 context switch전에 TLB Flush하는 것이다. 이는 작동하지만 많은 TLB miss를 발생시킬 수 있다.

두번째 방법은 ASID(Address space identifier)를 사용하는 것이다. 이는 Hardware의 도움을 받아 TLB에 ASID 정보를 추가해서, 프로세스마다 다른 ASID를 통해 주소변환을 수행하도록 한다. 이 방법은 TLB hit ratio를 훨씬 올릴 수 있다.