[Architecture] Building the MMU (2)

이제 TLB (Translation Look-aside Buffer)까지 적용된 MMU의 동작을 살펴볼 차례이다.

CPU에서 생성된 virtual address는 맨처음 TLB를 살펴보고 기존에 저장된 cache data중 원하는 VPN->PPN 정보가 있는지를 찾게 된다. 보통 여기서는 miss의 가능성을 최대한 줄이기 위해서 size 자체는 작지만 fully-associative 형태의 SRAM cache가 들어간다. 만약 TLB에 원하는 데이터가 있으면 굳이 Page table을 거치지 않고, 직접적으로 physical memory에 접근할 수 있게 된다.

하지만 원하는 정보가 TLB에 없는 경우라면 virtual address는 page table쪽으로 가서 translation 작업이 이뤄지게 된다. 지난 포스트에서 계속 언급했던 것처럼 Dirty bit / Resident bit 등을 확인해서 translation 작업을 계속 수행한다. 만약 할당하고자 하는 page 영역이 resident 하면 여기에 들어있는 PPN(Physical Page Number)을 읽고 memory의 정보를 읽게 된다. 위의 그림에서는 묘사되어 있지 않지만, 이런 과정은 앞에서 언급했던 TLB에 cache가 되고, 만약 여기에 자주 접근하게 되면 굳이 이 page map을 거치지 않더라도 TLB를 통해서 직접적으로 physical memory에 접근하게 된다.

당연히 해당 page가 resident하지 않다면 MMU는 CPU에게 page fault signal을 전달하고 CPU는 그즉시 exception handler를 수행하면서 그에 맞는 코드를 수행하게 된다. 여기까지가 지난 포스트동안 계속 설명한 내용이다.

 이 TLB가 포함된 형태에서의 예제를 살펴보자.

위와 같은 환경이 있다고 가정을 해보자. 여기서 중요하게 볼 항목은 p, v, m 값이고 지난 예제들과 다르게 TLB가 하나 있다는 것이다. 

 - 첫번째 질문은 physical memory에 한번에 저장될 수 있는 page의 수이다. 이 값을 확인하려면 physical page number의 bit수인 m값을 가져오면 된다. 2^14 = 16KB 일 것이다.

 - 두번째 질문은 page table의 총 entry 수를 물어보는 것인데, 이 값이 virtual page number의 bit수인 v 값을 가져오면 된다. 역시 2^22 = 4MB 로 쉽게 구할 수 있다.

 - 세번째 질문은 만약 page table의 entry가 모두 Physical page number와 resident bit, dirty bit을 가지고 있다고 가정했을때 entry당 몇 bit이 필요하냐는 것이다. 그러면 physical page number는 앞에서 언급했던 m값을 가져오면 되고 m+2 (dirty bit + resident bit) 이 entry당 총 소요 bit가 되겠다.

 

- 네번째 질문은 page table에 들어있는 총 page 수인데, page는 기본적으로 byte 단위라는 것을 기억하고 앞에서 구한 값을 활용하면 된다. 우선 총 page table entry는 2^22(=4MB)이고, 한 page 당 소모 byte는 앞에서 구한 16(=m+2)를 byte 단위인 8bit으로 나눠주면 된다. 이렇게 구한 두 값을 곱하면 그게 결국 page table의 총 byte 수가 되는데, 계산해보면 2^23=8MB 를 구할 수 있다. 여기서 한 page당 2^p만큼 가지고 있으므로 이값을 총 byte 수에서 나눠주면 그게 총 page 수가 된다. 2^23 / 2^10 = 2^13 이라는 값을 구할 수 있다.

- 다섯번째 질문은 virtual memory가 실제로 physical memory에 할당될 수 있는 비율을 물어볼 수 있는데, 이 값은 간단하게 VPN과 PPN간의 비율로 구할 수 있다. VPN을 통해서 총 2^22만큼의 virtual page가 나오는데, 이중 PPN인 2^14만큼만 할당될 수 있고, 그 이후의 page들은 알고리즘을 통해서 swap out 되던지의 형태를 취해야 한다. 따라서 2^14/2^22 = 1/2^8 만큼이 할당될 수 있는 비율이다.

- 여섯번째 질문은 조금 종합적인 질문이다. virtual address 0x1804에 해당 하는 physical address를 구하는 것이다. virtual address를 보면 VPN과 offset에 할당된 bit을 나눠서 따져봐야 하는데, 주어진 환경에서 page size가 2^10으로 나와있는 것으로 보고 offset에 할당된 bit이 하위 10bit임을 알 수 있다. 그러면 

에 따라서 하위 10bit인 0x004가 offset인 것을 구할 수 있다. 물론 VPN에 할당된 bit은 총 virtual address의 bit수 32bit중 offset bit을 뺀 값이 되는데, 여기서는 VPN이 0x6이 된다. 일단 VPN값을 구했으니 이값을 바탕으로 TLB에 cached된 값이 있는지 확인해보면 두번째 entry에 딱 있는 것을 볼 수 있다. 이렇게 되면 굳이 page map을 거칠 필요없이 VPN에 mapping되어 있는 PPN이 0x2라는 것을 구할 수 있다. 이걸 다시 physical address로 역변환을 시키면 여기에 할당된 주소가 0x804라는 것까지 구할 수 있다.

- 똑같은 방법으로 0x1080을 physical address로 변환시키면 어떻게 될까? 미리 계산해보면 offset은 0x80, VPN은 0x4로 계산할 수 있는데 이 값은 현재 TLB에 없다. 따라서 page map을 통해서 mapping된 PPN을 찾아야 한다. VPN 4를 살펴보면 여기에 PPN 5가 resident하므로 그대로 이값을 활용하면 된다. 계산해보면 0x1480이라는 physical address를 구할 수 있다.

- 반대로 resident하지 않은 경우도 살펴볼 수 있다. 0x0FC라는 virtual address에 해당하는 physical address를 계산하려고 보면 해당 VPN(=0x0)에 해당하는 TLB를 살펴보면 값은 있으나 해당 entry의 resident가 0이므로 이 값을 쓸 수없고, page map을 살펴봐야 한다. 그런데 막상 page map의 VPN 0을 살펴봐도 resident bit이 0이므로 결국 page fault가 발생하게 된다. 이후에는 CPU가 page fault handler를 통해서 exception을 처리하게 된다.

지금까지 여러 질문을 통해서 TLB가 적용된 MMU의 동작형태를 살펴보았다. 그런데 잘보면 page map에 같은 PPN이 mapping되어 있는 entry를 볼 수 있다. 그런데 우리가 중요하게 봐야 할 것은 해당 entry가 resident하냐의 것이다. resident 하지 않는 것, resident bit이 0인 것은 무시되고 오직 1인 것만 보고 이에 대한 동작을 확인해야 한다.