호출빈도수가 높을수록 먼저 설계하면 좋겠다. 왜냐면 빈도수가 높다는건 그만큼 많이 사용되는것이고, 변경시 영향력도 클 것이라 예상되기 때문이다.
자주 사용했던 함수를 검색하면, 얼만큼 쓰이는지 확인해볼 수 있다.
pg_round_down (4)
is_user_vaddr (10)
thread_current (57)
설계는 분업할때 혼란을 주거나, 바뀔시 영향을 줄이기 위해서 진행된다. 위 함수들은 많이 호출되나 우선순위가 떨어진다. 역할이 단순, 기능도 적고, 내부 구조를 변경하는 일이 없다.
Project3 흐름도를 보면, 대부분의 작업은 핸들러(vm_try_handle_fault) 에서 이루어지는걸 알 수 있다. 그리고 이 함수에서는 실패처리를 판단하기 때문에 설계에서 중요하다 볼 수 있다.
페이지를 생성하거나 삽입하는 함수 역시 내부 구조를 변경하거나 추가하는 동작이 포함되므로 논의 대상이 된다.
vm_try_handle_fault()
- page fault 이후 stack growth, lazy loading, mmap 접근, invalid access 판단이 만나는 곳
spt_find_page() / spt_insert_page()
- SPT 내부 hash 조작 규칙을 한 곳에 모으는 곳
vm_alloc_page_with_initializer()
- anon/file-backed page를 같은 방식으로 생성하게 해주는 곳
vm_claim_page() / vm_do_claim_page()
- SPT에 있던 page를 실제 frame과 연결하는 곳
swap_in / swap_out / destroy
- anon page와 file-backed page가 서로 다른 동작을 같은 이름으로 제공하는 곳
do_mmap() / do_munmap()
- file-backed page를 SPT, lazy loading, write-back 흐름과 연결하는 곳
자료구조를 먼저보면서 드는 생각은 어떤게 필요한지라는 의문이였다. 무엇이 쓰이는지는 함수를 호출하면서 명확해진다. 그래서 함수 호출부터 먼저 고려하기로 했다.
그러나 팀적으로 이론적 설계가 추상적라는 느낌이 강해, 구현하고 나중에 정리하기 위해 모이기로 결정했다. 내 방식도 최선이 아닐 가능성이 높기 때문에, 이때는 다수결을 따르는게 알맞아 보였다.
그래서 구현해볼 자료구조는 SPT, Page, frame, aux 로 결정했다.