Project3를 정리하면서, 여태 정리했던 TIL들을 정리했다.
우선 PintOS 프로젝트 3를 진행하면서 명확하게 해야 하는 부분들을 먼저 정리하겠다.
PintOS에서 어떻게 가상메모리를 관리하는지에 대해서 정리해본다.
핀토스는 가상메모리 page들을 pml4로 관리한다. pml4는 multi_level로 구성되어있는 페이지 테이블이다.
- struct page
가장 나를 헷갈리게 했던 부분이, struct page이다.
struct page는 페이지를 관리하기 위해서 해당 페이지에 대해서 정보를 담아놓는 구조체이다. struct frame도 마찬가지이다.
페이지 구조체의 주소값을 통해가면 실제 페이지에 디스크 데이터를 매핑되어 있다. 처음에는 struct page가 실제 페이지를 의미하는 것으로 생각했지만, 해당부분은 달랐다.
그리고 이제 새롭게 추가된 lazy_load_segment방식으로 작동하기 때문에, 이제 page에 즉각적으로 data를 mapping 하는 방식이 아니다.
uninit_new() 함수를 통해 실제 페이지 할당에 필요한 데이터들을 struct page에 넣어주고, uninit_initializer()함수를 통해서 해당 구조체와 연결된 메모리를 실제로 초기화해주는 역할을 한다.
실제로 사용하는 페이지를 init으로 데이터를 넣는 단계와, initializer로 실제 페이지를 초기화하면서 할당하는 역할이 다른 이유는, 실제 사용시까지 데이터를 할당하지 않는 것이 시간적 공간적 이점을 얻을 수 있기 때문에 해당 방식으로 구현된 것.
- spt
그리고 spt(supplemental page table)는(은) 말그대로 보충하는 테이블이다. page를 관리하는 기본적인 page table은 이미 구현되어있는 pml4이다. 즉 spt는 pml4를 찾아본 이후에 찾아보는 table이다. 그래서 page fault가 발생하면(pml4에 해당하는 page 정보가 없는지 확인), spt에서 찾는다.
그래도 없으면, page를 새로 만들어서 file을 read해서 올리는 방식으로 작동한다. 초기에는 spt가 pml4를 대신하는 방식으로 작동하는 줄 알았으나, spt는 말 그대로 보조로 작동하며, 페이지를 메모리에 mapping하면 pml4에 업데이트를 해준다.
- Interrupt_frame
이 부분은 설명을 읽고 납득하고 넘어갔지만, 읽고 도움이 됐던 블로그 주소를 남겨놓을 것이다.
page_fault가 발생했을때, 어떤 영역에서 발생했는지에 따라서 if에 보관되어있는 정보가 최신화가 안된 상태로 넘어오는 경우가 있기 때문에, Thread에 저장해두었던 Stack포인터로 해당 값을 가져오는 방법으로 Stack pointer 위치를 찾아 페이지를 할당해주어야 한다.
팀원들과 함께 작성한 WIL 링크도 남겨놓도록 하자. 디버깅관련하여서는 굵직한 내용들은 TIL에 작성해 둔 내용과 크게 다르지 않으니 생략한다.
https://github.com/pintos-team02/project3_wil/blob/main/README.md
