[Memory] Address Translation

*이 글은 Coursera에서 제공되는 HW/SW Interface 강의를 요약한 내용입니다.

지금까지 다룬 virtual memory 관련 내용에 따르면 모든 process는 자신만의 virtual address space를 가지고, 필요할 때만 DRAM에 load 시켜서 일종의 cache처럼 사용한다고 했었고, 이를 위해서 mmu에 있는 page table을 사용한다고 했다.

결국 그때도 한 이야기지만 virtual page 각각의 Physical DRAM 어디에든 allocate 될 수 있고, 여기서 process간에 page를 share하거나 protect 할 수 있다. 간혹 위의 그림처럼 Process 1과 Process 2상의 virtual page 2는 Physical page 6에 맵핑되어 있기 때문에 또다른 physical page를 만들 필요없이 공유하면서 쓸 수 있고, 반대로 Physical Page 2는 Process 1에 대해서만 Page table이 정의되어 있기 때문에 Process 2에서는 접근할 수 없다. 이렇게 virtual address와 physical address간의 Address Translation을 통해서 sharing과 protection을 구현할 수 있다.

 또한 Page table내의 Page table entry에도 memory protection을 위한 bit들이 존재한다.

valid bit이야 이전 포스트에서 설명했던 것처럼 page fault를 위한 bit이다. 지금은 모든 virtual page들이 physical memory에 load되어 있는 상태이기 때문에 모두 set되어 있다. 여기서 주목할게 다음에 나오는 3개 bit인데 이게 permission bit이다. 물론 이 permission bit의 형태는 위처럼 3개일수도 있고, 다른 architecture에서는 다른 형식으로 정의되어 있을 수 있다. 아무튼 위의 예제에서는 각각 Read / Write / Execute permission 에 대한 permission bit이 정의되어 있다.(왜 ppt에서는 SUP bit이라고 표현했는지는 잘 모르겠다..) 예를 들어 공유하고 있는 physical page 6이 할당되어 있는 부분의 PTE를 살펴보게 되면 둘다 Write bit이 clear되어 있다. 이 말은 공유되어 있는 상태에선 어떤 process가 page의 내용물을 수정했는지 모를 수 있기 때문에 임의로 write 권한이 없게끔 한 것이다. 이런식으로 PTE에 permission bit을 더함으로써 memory protection을 할 수 있다. 이렇게 정의된 bit은 MMU에서 해당 memory에 access할 때마다 사용자의 요구와 권한이 일치한지의 여부를 확인하게 된다. 물론 일치하지 않으면 이전 포스트에서 설명했던 것처럼 뭔가 segmentation fault같은 exception이 발생하게 될 것이다.

 그럼 Address translation 관점에서 다시 Page Hit/Fault를 확인해보자.

먼저 CPU가 특정 memory 영역을 읽어오는데 필요한 Virtual Address를 MMU에게 보내게 되면 MMU에서는 자기가 가지고 있는 Page table에서 해당 Page Table Entry를 내보낸다. 이전 포스트에서 이 과정에선 인텔 ISA같은 경우는 CR3라고 하는 Page table Base register를 이용해서 찾는다고 했었다. 아무튼 이렇게 얻어온 PTE속 physical address를 memory나 cache에 전달해주고 해당 개체는 원하는 값을 다시 CPU에게 반환하게 될 것이다. 그런데 의문을 가질 수 있다. 결국 이렇게 한다는 건 MMU입장에서 보면 memory에 두번씩 접근하는 셈이기 때문이다. 위 그림에서도 Physical Address를 얻어오기 위해서 Memory에 PTE Address를 보내주고 다시 PTE를 얻어오게 된다. 그럼 아예 처음부터 뭔가 읽어오는 과정을 누가 해놓으면 안될까? 사실 이런 과정을 cache에서 많이 봐왔다. cache의 역할도 cpu와 memory간의 latency를 고려해서 자주 사용하는 데이터를 미리 읽어오고 필요할때만 접근하는 형태였는데 이렇게 Page Table과 관련된 내용도 뭔가 cache같은게 있어서 미리 읽어오면 좋지 않을까 싶다.

 또 Page Fault가 발생할 때도 동일하다.

이 때도 Memory로부터 읽어온 Page Table Entry가 없다는 것을 안다면 괜히 Memory에 Access하지 않고 바로 exception으로 넘어갈 수 있을 것이다. 결과적으로 위 두개 이미지중 2, 3번과정은 translation 과정에서 Memory access가 두 번씩 일어나게 하는 요인이 되는 것이다.물론 성능저하가 될 것이다.

 그러면 결국 이걸 해결하려면 앞에서 언급했던 대로 Cache를 달면 좋을거 같다.그래서 MMU속에 Translation용 cache가 들어있는데 이걸  Translation Lookaside Buffer(TLB)라고 한다. 앞에서 언급한 virtual page 와 physical Page 간의 address translation을 해주되 다 들어있는 건 아니고, 대략 128~256개의 Page Table Entry가 들어있다. 

 이것도 일종의 cache이기 때문에 동작 역시 똑같다. TLB에서 찾고자 하는 Virtual Page Number가 존재하면 Memory에 Access할 필요없이 TLB에서 자체적으로 Page Table Entry를 반환해주고 이 값을 토대로 Physical Memory Address를 활용할 수 있다.

이렇게 되면 Memory Access는 딱 한번 이뤄질 것이다. 그럼 Miss가 발생하면 어떻게 될까?

물론 이때는 기존보다 더 느려지게 될 것이다. 기존 과정보다 TLB miss를 확인하는 과정이 포함되기 때문에 memory access가 더 발생한다. 그런데 사실 TLB miss자체는 여타 cache miss보다는 발생할 확률이 매우 작다. wikipedia에 소개된 대로라면 TLB miss확률은 대략 0.01~1%에 그친다고 되어있으니까 Miss시 발생하는 overhead에 대해서는 고려할 필요가 없지 않을까 싶다.