회고 오늘은 Pint OS 프로젝트 3의 마지막 날이다. 모든 과제를 끝내지는 못했지만, fail의 수를 5개까지 줄일 수 있었다. 중간에 에러 처리에서 헛발질만 안 했어도 시간이 더 있었을텐데 아쉽다. Swapping이 마지막인 줄 알았는데, Swapping을 구현해도 5개의 테스트 케이스가 남는다. 동기화 관련 문제라고 하던데 여기까진 손을 못 대겠다.. 처음 터졌을 때부터 고쳤으면 수월했겠지만, 코드를 너무 많이 고친 지금은 손을 댈 엄두가 나지 않는다. 다음주 일주일 간은 프로젝트 4 Extra를 진행한다. 말 그대로 Extra라서 구현하는 것은 옵션사항이다. 결국 프로젝트 3가 가장 힘든 주간이 아니었나 싶다. 프로젝트 3의 주 내용은 Virtual Memory이다. 물리 메모리의 용량 한계로 ..
Stack Growth 프로젝트 2에서 스택은 USER_STACK에서 시작하는 단일 페이지(4KB) =였으나, 프로젝트 3에서 스택은 현재 크기를 초과하면 필요에 따라 추가 페이지를 할당한다! Stack Growth 개념은 이해했으나 구현에 벅찼지만, 뛰어난 동료 덕분에 구현을 마치고 이해할 수 있었다. Page Fault 시, 스택 포인터 Stack Growth를 수행하기 전에 현재 스택 포인터의 값을 얻어야 한다. System Call 또는 User Program에 의해 발생한 Page Fault 루틴에서 각각 syscall_hanler() 또는 page_fault()에 전달된 struct intr_frame의 rsp 멤버에서 검색할 수 있다. 또한, Page Fault로 잘못된 메모리 접근을 감지하..
보조 페이지 테이블의 복사 fork가 발생할 시, 보조 페이지 테이블의 복사를 수행해주어야 한다. process.c의 __do_fork()에서 supplemental_page_table_copy()를 호출하면서 보조 페이지 테이블의 복사를 수행한다. 우리는 이 함수를 구현해야 한다. 보조 페이지 테이블을 복사하는 이유는 다음과 같다. 프로세스가 fork() 시스템 콜을 통해 자식 프로세스를 생성할 때, 부모 프로세스의 가상 메모리 공간을 자식 프로세스로 복사해야 한다. 메모리 보호: 가상 메모리 공간의 복제와 공유를 통해 프로세스 간에 안전한 메모리 보호를 제공할 수 있다. supplemental_page_table_copy() 함수는 필요한 권한과 제약 조건을 유지하면서 보조 페이지 테이블을 복사하여 ..
in Pint OS 기존의 Pint OS는 Eager loading(Immediate loading) 방식이다. Eager loading은 데이터나 자원을 가능한 빠른 시점에서 로드하는 방식을 의미한다. 즉, 필요한 자원을 처음으로 요청하기 전에 미리 load하여 사용 가능한 상태로 준비하는 것의 의미한다. Pint OS의 Project 3 - Anonymous Page 파트에서는 이 Eager loading 방식을 Lazy loading 방식으로 바꿔주어야 한다. 따라서 Lazy loading 방식에 대해 공부하고 정리해보았다. Lazy loading의 구현은 userprog/process.c 에서 이루어진다. Lazy loading 지연 로딩. 프로그램이 필요한 데이터나 자원을 처음으로 요청할 때까지..
프로그램 실행 로직 initd() supplemental_page_table_init() process_exec() load() load_segment(): 파일 바이트를 페이지 단위로 나누고, 페이지마다 파일의 어느 영역을 읽어야 할지 설정 vm_alloc_page_with_inirializer(upage, lazy_load_segment): page 구조체 생성 및 할당(malloc), page 구조체와 유저 가상 주소(upage)를 매핑, page fault가 발생하면, lazy_load_segment()를 호출하도록 설정. uninit_new (new_page, upage, lazy_load_segment) spt_insert_page(): 보조 페이지 테이블 생성 및 page 데이터 입력 set..
