크래프톤 정글 2기 2 PintOS Memory Mapped Files 헷갈리는거

1) code

 

code 영역은 read-only로 page table에 mapping된다. 또한, sharable 하다는 특징이 있다.

 

디스크로부터 file의 내용이 변화없이 읽어져 와서 따로 변화를 백업해 둘 swap file을 만들지 않아도 되는 놈을 file-backed pages라고 하는데, code 영역이 실행파일 형태로 backed 되는 file-backed pages이다. 예를 들어 a.out이라는 executable file이 디스크로부터 메인메모리에 읽어져 오면, 이를 file-backed pages 라고 할 수 있는 것이다. 반대로 디스크의 어디에서 읽어져 온 지 불명확한 놈을 anonymous pages라고 한다.

즉 file-backed page -> 디스크로부터 메인메모리에 읽어져오는 code영역 파일

anonymous page-> 디스크의 어디에서 읽어져 온 지 모르는 놈, 스택 힙같은거 내용이 계속 바뀜으로 swap file 형태로 백업되어야함

 

만약 코드를 메인 메모리에서 지우려면, 그냥 삭제해주면 된다.

 

2) stack, heap

 

대표적인 anonymouse pages이다. 보통 zero page에서 시작해서 CoW를 통해 점점 늘어간다.

 

내용이 계속해서 바뀌므로 swap file의 형태로 backed 되어야 한다.

 

3) data

 

data영역은 file형태로 시작해서 만약 수정이 일어나면, CoW를 통해 업데이트한다.

 

내용이 계속해서 바뀌므로 swap file의 형태로 backed 되어야 한다.

 

추가 궁금한거

 

1. 왜 필요할때마다 스택의 크기를 늘려주지않고 stack growth 형식으로 1페이지씩 늘려주는지?

 

2.

어디에서 Page Fault가 발생했는지 체크해야하는데, 이를 위해서는 User program의 스택 포인터(rsp)의 현재 주소값을 알아야 한다.

사용자 프로그램에서 system call 또는 Page fault가 일어났을 때에는, 해당 프로세스의 intr_frame의 rsp 멤버값을 그대로 사용해도 된다.
왜냐하면 Page fault가 발생해서 모드 전환이 되었을 때, User program의 스택 포인터 값이 intr_frame->rsp에 저장이 되어 Page-Fault-Handler나 Syscall-handler에 인자로 전달되기 때문이다.

하지만, 커널 주소 공간에서 Page fault가 발생하는 경우는 상황이 다르다. 예를 들어 Context switching 중에 Page Fault가 발생할 수도 있기 때문이다.
하지만 프로세서는 유저에서 커널 모드로 전환되는 exception이 발생했을 때만 스택 포인터를 저장하므로, page_fault()에서 전달된 struct intr_frame의 rsp는, 사용자 스택 포인터가 아닌 정의되지 않은 값일 수 있다.

이런 이유로, 유저 모드에서 커널 모드로의 초기 전환에서, rsp를 thread 구조체에 저장하는 등의 다른 방법을 준비해야 한다.

 

3.  mmap에서는 열었던 file을 reopen()해주는 이유

User가 해당 fd로 close를 하더라도 munmap하지 않았다면 매핑이 유지되어야 하기 때문.
reopen을 하지 않고 원본을 사용하면 user에 의해 file이 close되었을 때 더이상 매핑을 유지할 수 없음