TLB
TLB는 프로세서 내에 있는 memory-management unit(MMU)의 한 부분이다. TLB는 하드웨어 캐시이다. 즉 메모리의 일종으로 메모리 안에 가상주소에서 물리주소로 변환할 때 필요한 내용들(PTE)을 담는다. 캐시이다 보니 메모리의 크기가 한정이 되어있고 모든 정보를 담을 수 없어 popular한 정보를 담는다.
가상 주소를 물리 주소로 변환하기 위해 프로세서 밖의 메모리의 PTE를 읽어서 VPN이 어떤 PFN으로 매핑이 되어있는지 확인해야했다. 이렇게 외부의 메모리를 접근하는 과정이 전체 프로세스의 성능을 저하시킬 수 있었다. TLB에서는 popular한 address translation 정보를 TLB라는 하드웨어 캐시로 복사해 오게 된다. 가상 주소를 물리 주소로 변환할 때, 일단 페이지 테이블로 가지 않고 프로세서 안에 있는 TLB에 정보가 있는지 확인한 후 정보가 있다면 메모리로 가지 않고 바로 물리 주소로 변환할 수 있게된다. 이렇게 TLB에 원하는 정보가 있을 때 TLB Hit 없으면 TLB Miss라고 하며 TLB Miss가 발생하면 이때 비로소 메모리에 가서 페이지 테이블에서 페이지 테이블 엔트리를 찾게 된다.
TLB Basic Algorithms
1: virtual address에서 vpn을 얻는다
2: vpn을 TLB_Lookup함수에 넣어 각각의 TLB 엔트리를 조사해서 vpn에 맞는 엔트리가 있는지 확인한다.
3:만약 success라면 TLB Hit가 발생한 것이어서 페이지 테이블로 가지 않고 바로 가상 주소를 물리 주소로 바꿀 수 있다.
5: virtual의 offset정보를 얻는다.
6: PFN을 TLB entry에서 꺼내와서 SHIFT연산을 한 후 offset과 or연산을 해서 물리 주소를 계산한다.
7: 물리 주소를 통해 메모리를 접근한다.
11: TLB를 찾아봤으나 해당되는 엔트리가 없어서 TLB miss가 발생했을 때
12,13: 하드웨어가 변환 정보를 찾기 위해 페이지 테이블에 접근한다.
16: PTE에서 정보를 꺼내서 VPN과 함께 TLB에 insert한다.
17: TLB miss가 발생한 명령어를 재실행 시킨다.
Example: Accessing An Array
TLB가 어떻게 성능을 향상시킬 수 있는지 예제를 통해 보자.
address space의 총 페이지 수: 16
offset: 16바이트
총 256바이트의 address space
페이지 테이블 entry도 16개가 필요(VPN이 16개 이므로)
하나의 가상주소 = vpn + offset
a[0]의 가상주소 = 06을 이진수로 바꾼 수 | 04를 이진수로 바꾼 수
a[1]의 가상주소 = 06을 이진수로 바꾼 수 | 08를 이진수로 바꾼 수
1: i가 0 일때, sum+=a[0];이다. a[0]의 내용을 가져오려면 이곳의 가상주소를 물리주소로 바꿔서 그 물리주소 안에 있는 값을 읽어와야한다. 가상주소를 물리주소로 바꿀 때 TLB의 엔트리를 확인한다. i=0일 때는 가상주소를 처음 접근하는 것이라 TLB Miss가 난다. VPN6이므로 하드웨어는 페이지 테이블 인덱스 6의 엔트리를 읽어와서 TLB에 insert하고 a[0]을 읽으라는 해당 명령어를 재실행한다.
i가 1 일때, a[1]의 내용을 읽어야 하는데, a[1]이 위치하고 있는 VPN06의 정보는 TLB 엔트리로 존재하고 있기에 TLB Hit가 발생한다. i가 2일때도 마찬가지이다.
지금까지의 TLB Hit와 TLB Miss
TLB Hit: 2
TLB Miss: 1
a[3]을 읽을때도 위와 마찬가지로 TLB miss가 발생할 것이며 a[4],a[5],a[6]을 읽을 때 TLB hit이 발생한다.
총 10번의 가상주소를 물리주소로 변환하는 과정 중 3번만 메모리에 있는 페이지 테이블을 접근한 것이고 나머지 7번은 TLB캐시 안에 TLB엔트리를 접근한 것이다.
-> The TLB improves performance due to spartial locality
Locality
캐시가 효율적으로 동작하려면, 캐시의 적중률을 극대화 시켜야 하고, 캐시의 적중률을 극대화 시키기 위해서 캐시에 저장할 데이터가 지역성(Locality)을 가져야한다.
Temporal Locality: 최근에 접근했던 주소값을 다시 접근하는 경향(for,while을 연상해볼 수 있다.)
Spatial Locality: 최근 접근했던 주소값 근처의 주소들을 접근하는 경향(Array을 연상해볼 수 있다.)
Who Handles The TLB Miss?
TLB Miss가 발생하면 인텔 프로세서와 같은 CISC 아키텍처에서는 하드웨어가 TLB Miss를 전적으로 담당하게 된다.
TLB Miss시 하드웨어는
페이지 테이블을 찾는다.
VPN을 기반으로 정확한 페이지 테이블 엔트리를 찾는다.
필요한 변환 정보를 추출한다.
TLB를 갱신한다.
TLB miss가 발생한 명령어를 재실행한다.
이렇게 프로세서가 직접 TLB를 관리할 때, 이 TLB를 hardware-managed TLB라고 한다.
RISC 프로세서는 software-managed TLB이다.
TLB 미스가 발생했을 때, 하드웨어는 단지 exception만 발생시킨다. exception이 발생되면 OS로 전환이 되고 운영체제 안에 있는 Trap Handler가 실행이 된다.
아래는 TLB Control Flow algorithm(운영체제가 관리)이다.
TLB entry
일반적으로 TLB는 32,64 or 128개의 엔트리를 가진다.
TLB는 fully associative 방식으로 설계된다. fully associative에서 변환 정보는 TLB 내에 어디든 위치할 수 있으며, 원하는 변환 정보를 찾는 검색은 TLB 전체에서 병렬적으로 수행한다.
TLB 엔트리는 대부분 아래와 같다.
TLB Issue: Context Switching
context switching이 발생할 때 TLB 이슈에 대해서 살펴보자.
A 프로세스가 VPN10번을 접근했는데 VPN10에 대한 정보가 아직 TLB에 없기에 TLB miss가 발생하였고, 하드웨어는 관련된 정보를 TLB에 넣어주게 된다.
VPN10번이 PFN 100에 매핑 되어있는 것을 볼 수 있다.
프로세스 A에서 프로세스 B로 컨텍스트 스위칭이 발생하였다. 프로세스가 자신의 address space안에 있는 VPN10을 접근한다. 이때 마찬가지로 TLB miss가 발생해서 TLB 엔트리를 하나 넣어준다
TLB 테이블 안에 엔트리만 보고서는 각각의 VPN이 어느 프로세스에 속하는지 구분하기 어렵다. mmu도 각각의 프로세스의 vpn을 구분하지 못해서 잘못된 가상주소에서 물리주소에 변환을 수행할 수 있다.
이러한 문제를 해결하기 위해 TLB안에 address space identifier(ASID)필드를 넣었다.
프로세스 A에는 ASID를 1로 주고 B에는 2로 주었다.
이제 mmu는 vpn을 찾으면서 각각의 ASID도 확인함으로써, vpn이 어느 프로세스에 속하는지 구분할 수 있기 때문에 가상주소를 물리주소로 실수없이 바꿀수 있게 된다.
Another Case
이전에 같은 프로그램에서 나온 여러개의 프로세스는 그 프로그램의 코드 영역을 공유해 물리 메모리의 공간을 절약할 수 있다고 배웠다.
동일한 물리 메모리를 공유할 때 페이지 테이블의 매핑만 설정해준다면 다른 프로세스에서 한 물리 메모리를 공유할 수 있고 물리 메모리의 사용량도 줄일 수 있다.
TLB Replacement Policy
TLB는 한정된 엔트리 개수만 가지고 있다.(32,64,128)
TLB가 꽉 차있는 상태에서 TLB엔트리가 하나 들어오려고 하면 기존에 있던 TLB 엔트리를 선택해서 하나 버려야 한다. 이때 어떤 TLB엔트리를 선택해서 버려야 할지를 결정하는 policy가 Replacement Policy이다.
TLB의 교체 정책으로 많이 사용되는 정책이 LRU정책이다.
LRU: 가장 최근에 사용되지 않은 TLB 엔트리를 선택해서 버린다.
-이러한 정책은 최근에 접근했던 페이지가 시간 지역성이나 공간 지역성에 의해 근 미래에 다시 접근될 것이라는 캐시기본정책에 기반하고 있다.
TLB entry: 3개
TLB miss : 11번
A Real TLB Entry
