[OS] TLBs : Faster Translations-Issues

이번에는 TLB Issue 에 대해서 알아보자

 

ISSUE 1 : TLB sharing

만약 process 두개가 TLB를 공유한다고 해보자.

두 프로세스의 VPN 값이 모두 10으로 동일 한데 PFN은 각각 100 170으로 다르다. 

그렇다면 동일한 TLB에 다음과 같이 저장 되어 있다면 VPN만 보고서는 PFN 값을 구별할 수 없게 되는데 그럼 어떻게 둘을 구분 지어야 하는가에 대한 문제가 발생하게 된다.

 

이를 해결하기 위해서 context switching 일어날 때마다 TLB를 초기화 시키는 방법이 있을 것이다.

하지만 이 방법은 언젠가 다시 context switching 돼서 돌아올텐데 TLB가 매번 초기화 되어 있을 것이므로 바람직한 방법은 아닐 것이다.

 

다른방법으로 해결하는 것이 Address Space Identifier(ASID)이다.

ASID를 통해 어떤 VPN인지 확인하는 것이다. 

참고)

실제 운영체제를 보게 되면 ASID는 보통 8bit로 이루어져 있다.

8bit라고 하면 2^8 = 256 가지만 표현 가능하고 그렇다면 process 개수가 그 이상으로 가면 어떻게 되느냐 라는 생각이 들 수 있을 것이다. 

하지만 실제 운영할 때 보면 program이 실행 될 때  배정되는 것이 pid라고 하면 ASID는 실제 수행되는 순간에 새로운 ASID 값이 dynamic 하게 배정되기 때문에 256가지로도 충분하다.

 

ISSUE 2 : Page sharing

이번에는 page를 sharing 하는 경우를 알아보자.

 

그렇게 하여 두 프로세스가 page를 share 하고 있다고 하자.

각각의 VPN은 다르지만 같은 PFN을 가리키고 있는 것을 확인할 수 있다.

이렇게 page sharing을 하게 되면 만약  physical memory에 공간(page)을 따로 각각 생성하지 않아도 되는 이점이 있게 된다. 

 

ISSUE 3 : Replacement Policy

TLB 사이즈가 32 64 128 정도의 entry만 가지고 있기 때문에  replacement 가 필수 이다.

새로운 entry를 TLB에 넣을 때 기존의 어떤 entry를 제거하고 넣을지는 방법이 여러가지가 있을 것이다.

 

-LRU(Least Recently Used)

: 최근에 잘 사용하지 않았던 것을 빼내는 policy 이다.

이 방법은 최근에 사용된 것이 다시 사용될 확률이 높을 것이라는 생각에서 나온 방법이다.

 

-Random

: 이것은 말 그대로 random으로 빼내는 policy 이다.

이 방법은 simplicity 하고 corner-case behavior 에 적합하다.

ex) 만약 n+1 개의 page 가 있고 TLB 사이즈는 n개라고 했을 때, LRU로 진행하게 되면 매 접근 마다 TLB miss 가 나게 되고 이러한 경우에는 Random policy가 더욱 효율적이라는 것이다.

 

 

 

참고)실제 TLB Entry는 다음과 같이 되어있다.

software-managed TLB 이다.