해당 포스팅은 PintOS 3주차에 배운 PintOS에 관련된 핵심적인 내용, OS의 동작 원리를 다룰 예정입니다.(수정할 점이나 궁금한점이 있으시면 댓글로 남겨주세요🙂)
저번주에 작성한 TIL에서 Page, frame 등에 대한 설명을 작성했었다
Project 3시작 당시 우리가 Project 2까지 작성했던 PintOS는 다음과 같이 동작한다.
Project2를 진행하면서 메모리 할당 및 Virtual Memory에 대한 개념이 부족했기에 인지 못했지만 다음과 같은 구조는 몇가지 문제가 있다.
위의 그림을 간단하게 설명하면 이러하다.
현재의 PiintOS는 Process Addr Space에서 Page Table을 통하여 Pysical Memory에 allocation한다.
이 때 문제는 Page Table에서 물리메모리가 바뀔경우 PintOS는 panic에 빠지게 된다.
이러한 문제를 해결하기 위해 기존에 어떠한 데이터가 있는지에 대한 정보를 가지고 있는 Supplemental Page Table(SPT)이라는 보조 페이지 테이블을 만들어 page_fault가 발생했을 때 SPT를 이용해 물리메모리(page)와 가상메모리(frame)을 Mapping가능하다.
SPT를 사용하게 되면 다음과 같은 로직을 거쳐 Page_fault를 해결한다.
page_fault 발생 시 즉, User Memory가 Page Table에 Mapping되어있는 Pysical Memory를 참조했는데 원하는 Pysical Memory를 찾지 못한 경우 page_fault_handler가 작업을 수행한다.
SPT를 확인하여 VA(Virtual Addr)과 mapping되어있는 PA(Pysical Addr)가
없는 경우 : 우리가 PintOS에서 보던 page_fault가 실행되고 오류를 출력 후 exit()
있는 경우 : 2번 과정으로 넘어간다.
PA에 frame을 alloc 한다.
disk에서 실행 가능한 file을 Read해온다.
PA를 SPT에 update해주어 page_fault가 났던 page와 mapping해준다.
새 page를 Page Table에 Write해준다.
이러한 과정으로 page_fault가 처리가 된다.
SPT의 역할은 크게 2가지이다.
- Page fault시 SPT에서 오류가 발생한 Page를 조회하여 데이터가 있어야할 위치를 확인
- Process가 종료될 때 Kernel이 SPT를 참조하여 어떤 resource를 free할 것인지를 결정
결국은 SPT는 Page Table의 보조 테이블이므로 복잡하지 않은 Structures로 구현이 가능하므로 다양한 선택지가 있다.
hash table이 시간복잡도가 낮고 pintOS 내에 구현된 함수가 있어 hash table로 SPT를 구현하였다.
PintOS가 inited 부터 page_fault가 일어나는 코드의 흐름도는 다음과 같다
이러한 코드 흐름을 이해하면서 추후 목표인 Anonymous Page, Stack Growth, Memory Mapped Files, Swap In/Out을 진행하면 보다 수월하지 않을까 싶다.
솔직하게 말하면 VM에 대해서 만만하게 봤다가 거하게 털린 주였다.
page, frame, page table etc.. 여러가지 구조체가 등장하고 이러한 구조체들의 관계를 통해 가상메모리, 물리메모리와의 관계를 지정해줘야 하고, 프로세스 크기에 따라 스택을 키워주니, swap을 해야하는 등등... 해야할 일들이 아주 많고, 개념이해도 많이 어려운거 같다.
"급할수록 돌아가라"는 말이 있는 것처럼 그냥 대충하고 넘어가기엔 개념 하나 잘못 이해하고 다른 걸 건드려버리면 debug_panic과 친구가 될 것이 분명하기에 조바심 내지말고 개념에 대해 명확히 이해하고 넘어가야겠다.
시간은 금이라고 했고, 정글에 입소한지도 두달 반이 넘어간다.
2월 초에 수료한 내가 지금의 나보다 발전해 있기를 바라면서 조금만 더 힘내고 노력하자