소스파일
- include/vm/vm.h, vm/vm.c
- 가상메모리에 대한 일반 인터페이스 제공
- 여기서 추가 테이블 구현
- include/vm/uninit.h, vm/uninit.c
- 초기화되지 않은 페이지(vm_type = VM_UNINIT)에 대한 작업 제공
- 모든 페이지는 초기에 초기화 되지 않은 페이지로 설정된 다음 익명 페이지 또는 파일 지원 페이지로 변환
- include/vm/anon.h, vm/anon.c
- 익명 페이지(vm_type = VM_ANON)에 대한 작업 제공
- include/vm/inspect.h, vm/inspect.c
- 채점을 위한 메모리 검사 작업이 포함된 파일 변경하면 안됨
- include/devices/block.h, devices/block.c
- 블록 장치에 대한 섹터 기반 읽기 및 쓰기 액세스를 제공, 이 인터페이스를 사용하여 스왑 파티션에 블록 장치로 액세스
메모리 용어
- 페이지
- 가상 페이지라고 하는 페이지는 길이가 4,096 바이트(페이지 크기)인 가상 메모리의 연속 영역
- 페이지는 페이지 정렬 되어야함 => 페이지 크기로 균등하게 나눌 수 있는 가상주소에서 시작해야함
- 64비트 가상 주소의 마지막 12비트는 페이지 오프셋
- 상위 비트는 페이지 테이블의 인덱스를 나타냄(그림 어떻게 되는지 모르겠음)
- 64비트 시스템에서는 4레벨 페이지 테이블을 사용
- 프레임
- 물리적인 메모리에 연속적인 공간
- 페이지와 마찬가지로 페이지 크기이고 페이지 정렬 -> 64비트 물리적 주소는 다음 과 같이 프레임 번호 와 프레임 오프셋 (또는 오프셋 ) 으로 나눌 수 있음
- X86-64는 물리적 주소에서 메모리에 직접 엑세스 하는 방법 제공하지 않음 -> Pintos는 커널 가상 메모리를 물리적 메모리에 직접 매핑 -> 커널 가상 메모리를 통해 프레임에 엑세스 가능
- Pintos는 물리적 주소와 커널 가상 주소 간 변환을 위한 기능 제공 어떻게?
- 페이지 테이블
- CPU가 페이지에서 프레임에 있는 물리 주소에 가상 주소를 변환하기 위해 사용하는 데이터 구조
- 페이지 테이블의 형식은 x86-64 아키텍처에 의해 결정됨
- Pintos에서는 페이지 테이블 관리 코드를 제공함(threads/mmu.c.)
- 슬롯 교체
- 스왑 파티션 디스크 공간의 페이지 사이즈의 영역
- 슬롯 배치를 결정하는 제한 사항이 프레임보다 유연하지만 페이지 정렬 했을때의 단점이 없어서 스왑 슬롯은 페이지 정렬 되어야 함
자원 관리 개요
다음 데이터 구조를 설계/구현 해야 함
추가페이지 테이블 : 페이지 테이블을 보완하여 페이지 폴트 처리 활성화
프레임 테이블 : 물리적 프레임 축출 정잭을 효율적으로 구현 가능
스왑테이블 : 스왑 슬롯의 사용량을 추적
따로 세가지를 구현할 필요는 없으며 관련 리소스를 통합 데이터 구조로 전체 또는 부분적으로 병합하여 구현하는 것이 더 편할 수 있음
각 데이터 구조에 대해 포함되어야 하는 정보를 결정해야 하고 데이터 구조의 범위 또는 전역과 해당 범위 내에서 필요한 인스턴스 수를 결정해야 함
디자인을 단순화하기 위해 이러한 데이터 구조를 페이징할 수 없는 메모리(예: calloc또는 에 의해 할당된 메모리)에 저장할 수 있습니다 malloc. 즉, 포인터 사이의 포인터가 유효한 상태로 유지된다는 것을 확신할 수 있습니다. 무슨말인지 모르겠음
성능 향상을 위한 추가적 구현
배열, 목록 비트맵 및 해시테이블이 포함됨, 배열은 가장 단순한 접근 방식이지만 특정 위치를 찾기위해 긴 목록을 탐색하는 것은 시간낭비를 야기
고급 데이터 구조(ex> 균형 이진 트리)를 구현하는 것은 추천하지 않음
추가 페이지 테이블 관리
페이지 테이블 형식에 따른 제한 때문에 사용되며 각 페이지에 대한 자세한 데이터가 있는 페이지 테이블
추가 페이지 테이블의 사용 목적
- 페이지 폴트에서 커널이 추가 페이지 테이블에서 폴트가 발생한 가상 페이지를 찾아 거기에 있어야 하는 데이터를 찾는 것
- 커널은 프로세스가 종료 될 때 추가 페이지 테이블을 참조하여 해제할 리소스 결정
추가 페이지 테이블의 두가지 접근 방식
- 세그먼트 측면 : 연속적인 페이지 그룹, 실행 파일 또는 메모리 매핑된 파일을 포함하느나 메모리 영역
- 페이지 측면
페이지 폴트 처리
추가 페이지 테이블의 가장 중요한 사용자는 페이지 폴트 핸들러
프로젝트 2에서 페이지 폴트는 커널이나 사용자 프로그램의 버그였으나 프로젝트 3에서는 파일이나 스왑 슬롯에서 페이지를 가져와야 함
- 추가 페이지 테이블에서 장애가 발생한 페이지를 찾음 -> 메모리 참조가 유효한 경우 추가 페이지 테이블항목을 사용하여 파일 시스템이나 스왑 슬롯에 있거나 단순히 모두 0인 페이지일 수 있는 페이지에 들어가는 데이터를 찾음 공유(예: Copy-on-Write)를 구현하는 경우 페이지의 데이터가 이미 페이지 프레임에 있을 수도 있지만 페이지 테이블에는 없을 수도 있음 추가 페이지 테이블이 사용자 프로세스가 액세스하려는 주소에서 데이터를 기대해서는 안 된다고 표시하거나 페이지가 커널 가상 메모리 내에 있거나 액세스가 읽기 전용 페이지에 쓰려는 시도인 경우, 액세스가 유효하지 않고 유효하지 않은 액세스는 프로세스를 종료하고 모든 리소스를 해제
- 페이지를 저장할 프레임을 얻음 -> 공유를 구현하는 경우 필요한 데이터가 이미 프레임에 있을 수 있으며 이 경우 해당 프레임을 찾을 수 있어야 함
- 파일 시스템에서 데이터를 읽거나 스왑하거나 0으로 만드는 등의 방법으로 데이터를 프레임으로 가져옴
공유를 구현하는 경우 필요한 페이지가 이미 프레임에 있을 수 있으며 이 경우 이단계에서 조치가 필요하지 않음
프레임 테이블 관리
- 프레임 테이블은 각 프레임에 대해 하나의 항목을 포함
- 프레임 테이블의 각 항목에는 현재 점유하고 있는 페이지에 대한 포인터와 사용
ref)
1. https://casys-kaist.github.io/pintos-kaist/project3/introduction.html
