✍️ [PintOS] file.c 기반 가상 메모리 동작 퀴즈 정리
PintOS의 file-backed 페이지 처리 로직을 담당하는 file.c의 전체 흐름을
퀴즈 형식으로 복습해보며 동작 원리와 예외 처리를 점검했다.
특히 mmap/munmap, swap-in/out, lazy loading 시의 공유 페이지 처리에 집중하였다.

✅ Q1. 공유 프레임을 사용하는 이유는?
문제 요약
- 어떤 상황에서 여러 페이지가 같은 프레임을 공유하는가?
- swap-out 시 어떤 처리가 필요한가?
풀이 요약
- mmap()된 파일은 여러 페이지가 같은 물리 메모리 프레임을 공유할 수 있다.
예: 같은 파일을 여러 가상 주소에 매핑
- swap-out 시
frame->page_list에 있는 모든 페이지들을:
- dirty 여부 검사 후 write-back
- file_list에 따로 저장해두고
- 매핑 해제 (pml4_clear_page)
포인트
- 하나의 frame을 여러 page가 공유할 수 있다는 점이 file-backed 페이지의 핵심
- swap-out 시 file_list를 만들어 swap-in 때 다시 붙여주는 설계 구조가 중요
✅ Q2. lazy_load() 함수의 동작 순서
풀이 요약
- aux 구조체 파싱 (file, offset, read_bytes 등)
- 사용 후 aux 메모리 해제
- 파일 시스템 락 획득
- file_seek로 오프셋 이동
- file_read로 read_bytes만큼 읽음
- 나머지는 memset으로 zero fill
- 락 해제 후 true 반환
포인트
- zero_bytes는 메모리를 초기화할 범위임 (읽은 바이트 이후부터 페이지 끝까지)
- 이 함수는 page fault 발생 시 호출됨
✅ Q3. file_backed_swap_in()에서 루프를 도는 이유
풀이 요약
file_list에 있는 페이지들은 이전에 같은 프레임을 공유하던 페이지들
- swap-in 시 다시 frame에 연결해주고, MMU에 다시 VA → KVA 매핑을 걸어준다
- 리스트로 pop하고 page_list에 push_back + pml4_set_page()
포인트
- 한 페이지만 복원하는 게 아니라, 공유 중이던 모든 페이지를 복원해야 함
✅ Q4. do_mmap() 실패 조건 중 틀린 것
정답
풀이 요약
- read_bytes == 0이면 전부 zero fill 하면 되기 때문에 문제가 없음
- 반면 다음은 모두 실패 조건:
- A. offset이 파일 길이보다 큼
- B. 매핑할 주소에 이미 page 존재
- C. file이 NULL
✅ Q5. file_backed_destroy()의 write-back 조건
풀이 요약
- pml4_is_dirty()가 true일 경우 write-back 수행
- 그 외에는 write 안 함
- cnt_page > 0이면 아직 다른 페이지가 이 프레임을 공유 중이므로,
현재 페이지만 매핑 해제 (pml4_clear_page)
포인트
- 마지막 하나만 남았을 때는 clear 대신 frame 자체가 해제됨 (destroy → dealloc)
✅ Q6. do_munmap()에서의 누수 위험 요소
풀이 요약
다음 항목들을 놓치면 메모리/리소스 누수가 발생할 수 있음:
- 프레임 참조 수 감소 안함 → frame 해제 누락
- file_close() 호출 누락 → 파일 핸들 누수
- SPT에서 hash_delete() 안함 → 논리적 접근 누수
- pml4_clear_page() 안함 → MMU 매핑 유지
포인트
- 이 함수는 페이지 단위로 순회하며 모든 리소스를 해제해야 한다
✅ 마무리 요약
이번 file.c 퀴즈를 통해 다음과 같은 개념을 정리할 수 있었다:
- file-backed 페이지는 공유될 수 있음 → 프레임 관리에 주의 필요
- swap-out → file_list 저장, swap-in → 다시 page_list로 복원
- lazy loading은 file_read + memset 구조
- munmap은 4가지 자원(프레임, 핸들, SPT, MMU)을 빠짐없이 해제해야 함
다음에는 anon.c의 로직들을 점검해보아야 할 것 같다.