[OS/OSTEP] 18.vm-paging : 메모리 페이징,PFN과 VPN #12

18.vm-paging

# 시작하며

 어떻게 보면 지금 블로그에 운영체제에 대한 것을 조금 빡세게 정리하고 있다. 거의 이틀의 걸쳐서 중간고사의 범위를 모두 포스팅하는 것이 목적이고, 계획대로라면 오늘 새벽안에는 포스팅이 끝나야 한다. 어찌보면 OSTEP을 1회독을 하기 전 이 페이징 부분이 가장 헷갈렸다. 그래서 OSTEP을 처음부터 읽고자 했던 것이고 어찌저찌 열심히 2회독을 돌리며 포스팅하는 시점에서 다시 페이징 부분에 들어왔다. 나름 확실히 이해하고 있다고 생각하는데, 이번 회독때 또 어떤 모르는것이 나올지 살짝 궁금해진다. 시작에 앞서 가장 중요한 개념 중 하나는 8bit는 1byte라는 사실일거 같다. 별거 아닌데 잘 기억하고 있어보자

세그멘테이션은 나름 좋은 모습을 보이는거 같지만, 공간 자체가 단편화를 유발시키는 문제점을 야기했다. 그렇기 때문에 할당할시 고려해야할 것이 많아 졌다. 그렇다면 공간을 동일 크기의 조각으로 나누는 것을 고려해볼 수 있는데 여기서 등장한 개념이 페이징(paging)이다. 페이지(page)라는 고정크기 단위로 나누고 페이지 프레임(page frame)이라는 개념을 도입해 물리메모리에서의 공간을 알려준다. 또 이러한 정보를 모은 페이지 테이블(page table)을 참조한다.

# 개요

총 크기가 64바이트인 주소공간을 4개의 페이지로 나눈다. 페이지는 고정적인 크기이기 때문에 각 페이지는 16바이트의 크기를 가질 수 있을 것이다. 

 참고로 약 10년전까지만해도 32비트 머신을 사용했고 근래는 64비트의 머신이 보급화 됐다. 32비트도 매우큰데, 64비트는 매우매우 크다. 주소를 64비트로 표현할 수 있는 것이다. 교재에서는 32비트는 테니스코트면 64비트는 유럽크기만하다고 비유했다.

 이제 이 4개의 페이지를 128바이트의 물리주소에 배치해보자. 페이지의 장점은 어디에다가든 넣어 줄 수 있다. 굳이 연속되지 않아도 된다는 말이다. 또한 페이지의 크기가 가상주소에서 16바이트면 물리주소에서도 똑같이 16바이트이다.

 

이제 운영체제는 프로세스마다의 페이지 테이블(page table)이라는 자료구조를 유지한다. 여기에는 가상페이지가 물리페이지 어디에 맵핑 되어있는지를 저장한다. 페이지 테이블의 가상페이지의 순서를 인덱스로 사용한다. 예를들어 (VP0 -> PF3)( VP 1 -> PF 7 ) , ( VP 2 -> PF5), (VP 3-> PF2)의 순서로 테이블을 구성한다. 위에서 언급했던거와 같이 이러한 모양의 페이지테이블은 프로세스마다 존재해야한다.

 

위 코드는 해당 가상주소에 접근하여 가져온 데이터를 eax레지스터에 저장시키는 코드이다. 가상주소는 이제 두가지로 나뉘게 된다. VPN(Virtual page number)와 offset으로 말이다. 가상주소를 64바이트(2^6)라고 가정한 위의 예에서는 페이지 크기를 16바이트라고 했다. 그렇다면 가상주소는 4개의 페이지를 가져야 하기때문에, 2bit는 VPN을 표현하는데, 4bit는 offset을 표현하는데 사용된다.

이제 위 개념을 실제로 대입해보자. 가상주소(virtual address)가 21이라고 가정해보자. 2진수로 표현해보면 010101이 될 것이다. 

이제 우리는 페이지테이블(page table)로 이동한다. 그리고 인덱스를 1로하 접근하여 해당 페이지 테이블에서 PFN(Page Frame Number)의 값을 알아낸다. 그 알아낸 페이지프레임에서 offset만큼을 이동하면 원하는 주소가 되는 것이고, 원하는 데이터가 들어있다.

 여기서는 VPN을 이용해 얻어낸 PFN은 이진수 111이었던 것이다. 

 

# 페이지 테이블은 어디에 저장 되는가?

 32비트 머신은 32비트로 주소공간(가상주소)을 표현할 것이다. 보통 4KB(2^12)의 페이지 크기를 가지게 된다. 이 12비트는 결국 offset이라고 볼 수 있다. 그렇다면 32비트 중 12비트는 offset 나머지 20비트는 VPN을 표현하게 된다. 2^20은 대략 백만이라고 한다. 그렇다면 페이지 테이블에는 이 2^20개의 요소( VPN과 PFN의 맵핑 관계 표현)들을 저장하고 있어야한다. 이 것을 PTE(Page table entry)라고 하는데, 이 PTE를 표현하는데 4바이트(32bit)가 필요하다는 가정을 하면 각 페이지 테이블 저장에만 4MB가 필요하고 프로세스가 100만개라면 400MB가 필요하다. 64비트는 말도안되게 클 것이다. 이렇게 큰 값을 저장해야하기 때문에 각 프로세스들의 페이지테이블은 메모리에 저장한다. 일단은 물리 메모리에 상주한다고 가정한다.

PFN0에 페이지 테이블이 존재하는 것을 알 수 있다. 페이지테이블은 위에서 언급했던거와 같이 VPN을 인덱스로 찾아가면 쉽기 때문에 선형테이블(liner page table)로 많이 구성한다. 

 

# 페이지 테이블에는 무엇이 있는가?

먼저 페이지 테이블은 PTE로 구성된다. 이 PTE는 각각 페이지프레임에 대한 정보를 가지고 있다. 이제 그 안에는 뭐가 있는지 하나씩 정리해보자.

 Vaild bit는 해당 프로세스가 사용하지 않는 공간에 접근하는 것을 막기 위해서 존재한다. 뒤에서 배우는 TLB에서도 Vaild bit가 나오지만 명확한 쓰임은 다르기 때문에 유의해야한다. 현재 프로세스가 사용하는 페이지에 대해서만 vaild bit로 설정하고 나머지는 invalid bit로 설정한다면 해당 프로세스에서 해당 주소로 접근하기위해 거치는 페이지 테이블에서 Valid bit를 우선적으로 판단한다.

 Protection bit는 읽기전용에 쓰려고 하거나 하는 등의 정보를 가지고 있어서, 용도 맞는 방식으로 사용하는지를 검사한다.

 Present bit는 이 페이지가 물리 메모리에 있는지 혹은 디스크에 있는지를 판단한다. 물리 메모리에 없으면 디스크에서 해당 정보를 불러와야한다. 물리 메모리에 없다고 쓰이지 않는 정보는 아니라는 것에 주의하자

 dirty bit는 해당 메모리의 데이터를 수정했는지 확인한다. 만일 수정했더라면, 디스크에 수정된 값을 언젠가 저장해야한다. 그 것에 대한 정보를 제공해준다.

 reference bit는 페이지에 접근했는지에 대한 추적하는데 사용한다. 뒤에서 페이지 교체정책에 대해서 공부할때 다시한번 정리하겠지만, 최근에 접근했다면 스왑되는 우선순위에서 뒤로 밀리게 된다. 즉 인기있는 페이지인지를 판단한다. 인기가 있는데 디스크로 내리면 그 페이지는 또 쓸 일이 있다는 말인데, 디스크에서 메모리로 읽어오는 작업은 자원이 많이 쓰이기 때문이다.

아래는 32비트의 PTE가 실제로 구현된 보습이다.

 

# 페이지 테이블의 단점 : 너무 느림

 사실 이 페이지를 사용하는 것은 꽤 느리다. 왜 느린지 한번 봐보자.

이제 가상주소 21로 접근해야한다. 가상주소를 물리적 주소로 변환해야 한다. 그러기 위해서는 페이지 테이블에서 VPN에 기반하여 PTE를 가져와야 한다. PTE에서 가져온 PFN을 통해서 다시한번 주소접근을 한다. 먼저 페이지 테이블의 위치를 알아야하는데 이는 페이지 테이블 베이스 레지스터(page table base register)라 불리는 곳에 페이지 테이블의 시작 주소가 적혀있다. base-bound 방법을 했을때와 같은 방식이다. 

6번과 16번 라인에서와 같이 두번의 메모리접근이 요구 된다. PTE를 알아내기 위해서 한번, PFN과 offset을 조합한 최종 물리주소에 접근 한번 말이다. 메모리 참조는 비용이 매우 비싸다. 

극단적인 예가 교재에 있다.

아래 반복문을 실행해보면



한 루프를 도는데 10번의 메모리 참조가 발생한다고 한다.

# 정리

 페이지 테이블을 구성하는데는 너무 많은 메모리가 사용되고 하드웨어의 도움이 없이 위에처럼만 구성한다면 너무 느려진다는 것이다. 이제 하드웨어의 도움을 받아 페이징을 구현하면서 페이징이 야기하는 문제를 하나씩 줄여나가 보자