jun-wiki
프로젝트 2 끝났다고 좋아하기는 이르다
프로젝 3 들어가자
프로젝트 3 가상 메모리
실행 스레드 동기화와 실행 가능해졌지만
실행 가능한 프로그램의 개수와 크기는 실제 메인 메모리의 용량에 제한된다
이번과제에서는 메모리를 무한으로 보이게 해서 이 제한을 없앨 거다
즉, 가상 메모리 만든다는 거다
배경
소스 파일
건드려야 할 곳이다
이상한 곳 건드리지 않게 유의하자
include/vm/vm.h,vm/vm.c
- 가상 메모리의 일반 인터페이스를 제공한다
- 보조 페이지 테이블을 여기서 구현한다
vm_type의 정의와 설명을 볼 수 있다VM_UNINITVM_ANONVM_FILEVM_PAGE_CACHE(프로젝트 4용이라 지금은 무시)
include/vm/uninit.h,vm/uninit.c- 미초기화 페이지 처리
- 현재는 모든 페이지가 처음에 미초기화였다가 익명 페이지(
VM_ANON) 혹은 파일 기반 페이지(VM_FILE)로 변환
include/vm/anon.h,vm/anon.c- 익명 페이지(
VM_ANON) 처리를 제공한다
- 익명 페이지(
include/vm/file/h,vm/file.c- 파일 기반 페이지(
VM_FILE) 처리를 제공한다
- 파일 기반 페이지(
include/vm/inspect.h,vm/inspect.c- 채점용 메모리 검사 연산 수정 X
메모리 용어
페이지
페이지는 알다시피 4kB, 정확히는 4,096바이트다 palloc 많이 써서 안다
아무튼, 가상 페이지도 4,096바이트 짜리 가상 메모리 구간인데
페이지 정렬로 이루어져야 한다
63 48 47 39 38 30 29 21 20 12 11 0
+-------------+----------------+----------------+----------------+-------------+------------+
| Sign Extend | Page-Map | Page-Directory | Page-directory | Page-Table | Page |
| | Level-4 Offset | Pointer | Offset | Offset | Offset |
+-------------+----------------+----------------+----------------+-------------+------------+
| | | | | |
+------- 9 ------+------- 9 ------+------- 9 ------+----- 9 -----+---- 12 ----+
Virtual Address
하위 12비트는 오프셋, 상위 비트들은 페이지 테이블의 인덱스로 사용된다
오프셋(12비트)은 페이지 내부 바이트 위치(0~4095)를 알 수 있고
각 인덱스(각 9비트)는 해당 레벨 테이블에서 512(=2^9)개 엔트리 중 하나를 고르는 거다
PML4(최상위) → PDPT → PD → PT(최하위) → PT 엔트리(PTE)
Sign Extend는 말그대로 연장한거라 47비트 값으로 꽉 채우면된다 47비트가 1이었으면 1로, 0이었으면 0으로
각 프로세스는 KERN_BASE(0x8004000000) 이하의
사용자(가상) 페이지 집합을 독립적으로 가지나
커널(가상) 페이지 집합은 전역이다
커널은 어떤 스레드든 프로세스든 위치가 같다는 거다
커널은 사용자/커널 페이지 모두 접근 가능하지만
사용자 프로세스는 자신의 사용자 페이지만 접근 가능하다
Pintos에서 가상 주소 다루기 위한 함수들도 존재한다
Virtual address참조
추가로 KERN_BASE가 뭐고 왜 0x8004000000인지도 알아봤다
KERN_BASE는 경계값이다
프레임
프레임은 물리 메모리 상의 페이지 크기이지 정렬된 연속 구간이다
64비트 물리 주소는 프레임 번호와 오프셋으로 나뉜다
12 11 0
+-----------------------+-----------+
| Frame Number | Offset |
+-----------------------+-----------+
Physical Address
x86-64는 물리 주소로 직접 메모리에 접근하는 방법을 제공하지 않는다
Pintos는 이를 우회하기 위해
커널 가상 메모리를 물리 메모리에 일대일로 매핑한다
난 여기가 잘 이해가 안 갔다
가상 메모리 거쳐서 물리 메모리 만지는 거나
물리 메모리 바로 만지는 거나 동일한 거 아닌가?
명령어 누가 주느냐 차이 정도기에 하나 안되면 둘 다 안되야 한다고 생각되었고
만약 둘 다 동일하게 접근 하는 거라면 사실상 눈가리고 아웅하는 거나 다를 바 없어보여 말이다
다행히도 좀 더 알아보니 이해가 되었다
기본적으로 물리 메모리 접근 방법이
-
명령어 가상 주소 받음
-
TLB에서 VA→PA(물리 주소) 번역을 찾음 (miss시 PTE로)
-
권한/보호 검사
-
캐시/메모리 접근
이 순서로 진행되기에
애시당초 직접 접근하는 방식이 없는 거였다
그렇지만 커널OS 직접 접근하듯 다룰 필요가 있기에
커널 가상 메모리와 물리 메모리를 1대1로 매핑 시킨거였다
KERN_BASE보다 큰 가상 주소는 물리 주소 0을, 가상 주소 KERN_BASE + 0x1234 는 물리 주소 0x1234 를 대응해주는 식으로 말이다
페이지 테이블
페이지 테이블은 CPU가 가상 주소 → 물리 주소(페이지 → 프레임)로 변환할 때 사용하는 자료구조다
pintos에서는 threads/mmus.c에 페이지 테이블 관리 코드가 있다
페이지와 프레임 관계
+----------+
.--------------->|Page Table|-----------.
/ +----------+ |
| 12 11 0 V 12 11 0
+---------+----+ +---------+----+
| Page Nr | Ofs| |Frame Nr | Ofs|
+---------+----+ +---------+----+
Virt Addr | Phys Addr ^
\_______________________________________/
스왑 슬롯
스왑 슬롯은 스왑 파티션 내의 페이지 크기 디스크 공간 구간이다
스왑 파티션이 무엇이냐?
디스크에서 스왑 용도로만 쓰라고 따로 떼어 둔 전용 구역이다
보통 페이지 정렬로 둔다
굳이 페이지로 해야한다는 제약은 없지만 보통 스왑 자체를 페이지 단위로 하는데다가
페이지 테이블이나 보조 페이지 테이블로 하여금 가상 페이지, 슬롯 번호만 기억하면 되도록 설계할 수 있어 깔끔하다
디스크 I/O도 페이지 한번만 읽고/쓰기면 끝이라 효율적이기도 하다
자원 관리 개요
자료 구조 설계/구현해야 하는 것들이다
-
보조 페이지 테이블 (Supplemental Page Table, SPT)
- 페이지 폴트 처리를 위해 필요
-
프레임 테이블 (Frame Table)
- 물리 프레임의 eviction(축출) 정책을 효율적으로 구현하기 위해 필요
-
스왑 테이블 (Swap Table)
- 스왑 슬롯 사용 현황을 추적
원한다면 부분적으로 통합하거나 해도 괜찮다고 한다
각 자료구조마다 원소에 담길 정보, 스코프(프로세스 로컬 vs 시스템 전역), 인스턴스 개수를 결정해야 한다
이 자료구조들을 비페이지 가능 메모리(malloc, calloc으로 할당) 에 저장해도 좋다고 한다
구현 선택지 (성능 관점)
배열(array), 리스트(list), 비트맵(bitmap), 해시 테이블(hash table) 등을 사용 ㄱㄴ
비트맵과 해시 테이블이 성능 좋으니 애용하라는 내용이다
보조 테이블 관리
여기부터는 다음에 먹겠다
더 찍먹했다간 과식으로 심장마비 오는게 빠를테니…