먼저 userprog/process.c를 보자. 

 process_execute() 가 실행되면, thread_create가 실행되고, start_process함수가 실행된다.

 "start_process()"함수에서는 stack-pointer를 초기화 시키고 file를 load한다. (이 과정에서 argument passing도 하겠지)

file을 Load할 때, thread의 pagedir를 초기화시킨다. (이제부터는 이 pagedir를 중심으로 따라가보겠다.)

pagedir이 pagedir_create()함수에 의해 초기화되면, 여기에는 새롭게 메모리로부터 할당된 page_directory의 포인터가 할당된다.

새로운 pagedir는 핀토스가 제일 처음 실행될 때 만들어진 base_page_dir로 초기화 된다. base_page_dir를 초기화 하는 과정은 threads/init.c의 page_init()함수에 보면 잘 나와있다.

page를 initialize한 후 process_activate함수를 실행시키는데, 여기에서 pagedir_activate가 일어난다. 이는 pagedir를 CPU의 레지스터로 올려주는 역할을 한다.

초기화가 완료되면 file을 읽어서 메모리 상에 올려주어야 한다. 이게 좀 코드가 더러운데, 쉽게 얘기하자면

 CODE, DATA, STACK순으로 하나하나 load시켜준다. 이 하나하나가 segment라고 불리우고, 이것을 load시키는 함수가 바로 load_segment함수이다. 

file_page를 통해서 file의 위치를 가져오고, mem_page를 통해서 파일을 저장할 메모리의 virtual address를 가져온다.

load_segment함수에서는, 먼저 kpage라는 포인터로 일정 메모리를 할당받은 후 파일을 읽어 kpage에 저장하고, 이를 virtual address에 연결시켜준다. (install_page (upage, kpage, writable)에서 mapping을 함)

근데 보면, pagedir는 page-directory라는 테이블을 만들고, 그 안에 들어간 element들, 즉 page-directory-entry는 각자 자기 자신의 page-table 를 pointing하고 있다. page-table-entry는 physical memory를 pointing하고 있다. 각 process는 자기만의 page directory값을 가지고 있기 때문에, virtual address는

  "pde(page directory의 index) addr + pte (page table의 index) addr + offset" 

으로 구성되는 것이다. 

 하지만 이를 통해서 swap을 효율적으로 실행시킬 수는 없다. 

 물론, 핀토스를 통으로 뜯어 고쳐서 swapping을 구현하고, 이를 통해 page-fault handling을 하면 좋겠지만, recommended에서는 절대로 그렇게 하지 말라고 한다. 결국, 현재 있는 구조를 그대로 살린 채 추가적인 구조체를 덛씌워서 메모리 관리를 시켜주어야 한다.

 그래서 등장하는것이 supplementary page table, frame table, 그리고 swap table이다.

 supplementary page table은 기존의 page table을 보완하기 위해 만든 것이다. 첫째 이유. page-table entry가 physical address를 가리키고 있지만, 다른 page-table entry도 같은 physical address를 가르킬 수 있다. 왜냐햐면 page-table은 page-directory-entry마다 하나씩 가지고있고, 서로다른 virtual address를 가지지만 같은 physical memory를 참조하는 경우가 충분히 발생할 수 있기 때문이다. referencing하고있는 table들은 전부 다르지만, 결국 같은 physical address를 가르키고 있는 것이다. 이러한 경우를 다루기 위해서는 하나의 프로세스가 어떠한 physical memory를 참조하고 있는지에 대한 정보가 필요하고, 이를 위해서 추가적인 page table이 필요한 것이다.

 두번째 이유. 기존의 page-table은 physical memory를 향한 일방적인 pointing에 불과하다. 때문에 physical-memory의 값이 바뀌어 있으면 패닉에 빠질 수 밖에 없다. 기존에 어떠한 데이터가 있는지에 대한 정보를 전혀 가지고 있지 않기 때문에 이러한 문제가 발생하면 해결할 수가 없다. 따라서 supplementary page table에는 원래 physical-memory에 들어가 있어야 할 데이터가 어떤것인지에 대한 정보를 가지고 있어야 한다. 

  마지막 이유. resource-free를 할 때에 어떠한 데이터를 FREE할지를 결정하는데에 사용된다. 두번째 이유에서 설명한 것을 바탕으로 충분히 직관적인 이해를 할 수 있으리라 본다.

  Frame Table은 efficiently implement an eviction policy를 위해서 필요하다고 말한다. 

 "The most important operation on the frame table is obtaining an unused frame." 따라서, 제일 처음에 시작될 때 frame을 allocate시키는 것이 옳은 것 같다. 

  메모리상에 어떠한 부분이 비어있고, 어떠한 부분이 차 있는지를 관리하기 위해서 필요한 것이 바로 Frame Table이다. 혹 꽉 차있다고 하면, 어떠한 것을 evict시킬지 결정하는데에도 사용된다. 

  Swap Table은 실제 disk(보조 기억장치)를 관리하는 녀석이다. swap-table-entry는