거북이의 쉼터

저녁 먹고 돌아왔다. Anonymous Page의 매뉴얼을 읽어보자. 매뉴얼에 쓰여진 주된 사항은 anon.c의 코드를 수정하라는 것이다. VM_ANON 타입의 페이지는 이전 포스팅에서 언급한대로, 파일에서 기원하지 않은 모든 페이지, 즉 대다수의 페이지를 차지한다. 현재 실행되고 있는 프로세스의 내용, stack 등은 전부 VM_ANON 타입의 페이지로 메모리에서 관리된다. 그래서 구현해야 할 사항이 무엇인가 하고 봤다. 바로 Lazy Loading이 나온다. 지난 번에 언급했듯이 프로젝트 2까지 pintos는 전부 eager loading, 즉 페이지를 요청하자마자 페이지를 할당하여 내용을 채우고 반환하는 짓을 해왔다. 그러나 지금부터는 페이지를 요청한 뒤, 직접적으로 접근이 일어나기 전까지는 페이지..

보호되어 있는 글입니다.

지난 시간 설명 요약: 이번 포스팅에서는 Supplemental Page Table(후술 SPT)과 Frame Table(후술 FT)의 구조를 설계하는 것을 목표로 한다. 1) SPT SPT는 크게 제약 조건이 없다. 지난 포스팅에 설명한 것과 같이 struct page의 삽입, 탐색, 삭제 3개의 작업만 효율적으로 할 수 있으면 되는 구조를 선택한다. 이에 해당하는 자료구조가 바로 hash 테이블이며 이제 필연적으로 hash.c와 놀게 되었다. 매뉴얼의 hash 테이블에 해당하는 문서와 hash.c를 읽어본다. 일단 나에게 친숙한 형태의 hash 테이블은 구조체가 주어지면 해당 구조체를 어떤 hash 함수에 넣어 hash 값을 계산하고, 해당 hash 값을 토대로 O(1)의 탐색 과정을 거쳐 원하는 위..

아마 해당 주제의 포스팅이 개강 전 마지막 포스팅이 될 것 같다. 실제 코딩은 대전 내려가서 해야할 듯.... 좀 길어질 것 같아 2개로 포스팅을 나누려고 한다. 우선 포스팅을 작성하다보니 struct page 구조체와 실제로 메모리상에서 4kB의 공간을 차지하고 있는 page 용어가 헛갈릴 수 있겠다는 생각이 들어 struct page는 "페이지_정보_구조체"로, page는 "페이지"로 표기하기로 한다. 모든 페이지의 수월한 관리를 위해서 pintos는 해당 페이지의 종류, 연결된 프레임 등의 정보를 저장하고 있어야 한다. 이를 위해 pintos에서는 struct page(후술 페이지_정보_구조체)라는, 다음과 같은 구조체를 각 페이지마다 생성해서 관리한다. 해당 구조체에 미리 들어가 있는 것들은 수정..