[Pintos] project3
임시저장용 test
VIRTUAL MEMORY
반드시 주어진 템플릿을 따르세요. 이 말은, 주어진 템플릿에 기반하지 않고 코드를 제출한다면 당신은 0점을 받는다는 말입니다.
블록 디바이스 ⇒ 하드디스크, CD/DVD등의 장치로 블록, 섹터 등의 정해진 단위로 데이터를 전송
- I/O 전송속도가 높은 것이 특징(다른 종류로는 캐릭터 디바이스라는 것이 있음)
| Block Device | Character Device | |
| 데이터 전송 | System Buffer를 사용하여 데이터를 전송 | 데이터를 한 번에 한 문자씩 전송 |
| I/O 전송 속도 | 전송 속도가 높다 | 시스템의 I/O Buffer를 사용하지 않아 느릴 수도 있으나 버퍼처리를 응용프로그램이 제어하므로 응용프로그램의 성능에 따라 다를 수 있다 |
| 대표적인 장치 | 하드 디스크, 테이프 드라이버, 플로피 디스크, 광 자기 디스크 | 단말기, 프린터, 플로터 및 기억장치 |
스왑(Swap) 파티션
메모리가 완전히 가득 차면 추가적으로 실행되는 프로그램은 메모리가 아닌 스왑 파티션에서 실행 ⇒
메모리 공간이 가득 차서 부족할 때 프로그램 실행이 가능하도록 에비 공간의 역할
우선 순위에 따른 처리
스왑 파티션은 메모리에 더 중요한 항목을 둘 여유 공간을 확보하기 위해, 일부 항목을 메모리에서 하드디스크로 옮기는데 도움을 줌 ⇒ 이 특성에 따라 우선순위가 낮은 항목은 스왑 파티션으로 이동할 것임
최대 절전을 가능하게
시스템 최대 절전 모드에서 메모리의 내용을 보관하는 장소로 사용 ⇒ 사용자가 이 기능을 사용하는 경우는 드뭄
스왑 파티션의 장/단점
- 스왑 파티션 장점:
- 메모리 부족 시 프로그램 실행을 가능하게 함(보조 공간 제공)
- 메모리 공간을 보존하여 더 중요한 항목에 우선순위를 부여할 수 있음
- 시스템 최대 절전 모드에서 메모리 내용을 저장하는 장소로 활용 가능
- 스왑 파티션 단점:
- 하드디스크 I/O 속도에 영향을 줄 수 있음
- 스왑 파티션 사용 시 프로그램 실행 속도가 저하될 수 있음
- 스왑 파티션은 동적으로 크기를 조정할 수 없어 하드디스크의 공간을 차지함
스왑 파티션은 시스템 성능에 큰 차이를 가져올 수 있다. (더 좋게 / 더 나쁘게)
- 스왑 활용도를 변경하는 방법
- gksu gedit /etc/sysctl.conf ⇒ vm.swappiness를 수정
- ex) vm.swappiness=10 ⇒ 메모리 사용률 90%에 스왑
Memory Terminology
Pages
가상 페이지(페이지)는 4,096바이트의 길이를 가지는 가상 메모리의 연속된 영역 ⇒ 반드시 정렬 되어야 함
1
2
3
4
5
6
7
8
페이지가 정렬되어야 하는 이유
- 페이지 테이블은 페이지 번호를 물리 주소에 매핑하는데 사용되며,
페이지가 정렬되지 않으면 페이지 테이블을 검색하거나 업데이트 하기 어려워짐
- 페이지가 정렬되면 페이지 경계를 넘어가는 주소에서의 페이지 처리의 비효율성을 제거
- 가상 메모리 시스템은 페이지를 디스크와 물리 메모리 사이에서 이동하고 관리하는데 사용되며,
정렬된 페이지는 이러한 작업을 단순화 시킴
- 캐시 블록의 활용도를 높임
- 페이지가 정렬되어 있지 않으면 스프트웨어 호환성 문제가 발생 할 수 있음
64bit 가상주소의 마지막 12bit는 offset / 상위 bit들은 페이지 테이블의 인덱스를 표시
64bit 시스템은 4단게 페이지 테이블을 사용
Intel X86 Page Table
- 각 프로세스는
KERN_BASE(0x8004000000) 미만의 가상주소값을 가지는 독립적인 유저(가상)페이지 집합을 가집니다. - 반면에 커널(가상)페이지 집합은 전역적이며, 어떤 쓰레드나 프로세스가 실행되고 있든 간에 항상 같은 위치에 남아 있습니다.
- 커널은 유저 페이지와 커널 페이지 모두에 접근할 수 있지만, 유저 프로세스는 본인의 유저 페이지에만 접근할 수 있습니다.
Frames
물리 프레임 / 페이지 프레임 등으로 불리는 프레임은, 물리 메모리 상의 연속적인 영역
- 프레임은 페이지사이즈여야 하고 페이지 크기에 정렬되어야 함
- 64bit 물리주소는 Frame Number / Offset으로 나누어 질 수 있음
1
2
3
4
5
12 11 0
+-----------------------+-----------+
| Frame Number | Offset |
+-----------------------+-----------+
Physical Address
x86-64 시스템은 물리주소에 있는 메모리에 직접적으로 접근하는 방법을 제공 X
⇒ Pintos는 커널 가상 메모리를 물리 메모리에 직접 매핑하는 방식을 통해서 이 문제를 해결
- 커널 가상 메모리의 첫 페이지 ⇒ 물리 메모리의 첫 프레임에 매핑
- 두번째 페이지는 두번째 프레임에 매핑
⇒ 커널 가상 메모리를 통하면 물리 메모리 프레임들에 접근 가능(pintos에서는 커널 가상주소와 물리주소 사이를 변환해주는 함수 제공)
Page Tables
페이지 테이블**
페이지 테이블은 CPU가 가상주소를 물리주소로, 즉 페이지 테이블로 변환하기 위해 사용하는 자료구조
1
2
3
4
5
6
7
8
9
+----------+
.--------------->|Page Table|-----------.
/ +----------+ |
| 12 11 0 V 12 11 0
+---------+----+ +---------+----+
| Page Nr | Ofs| |Frame Nr | Ofs|
+---------+----+ +---------+----+
Virt Addr | Phys Addr ^
\_______________________________________/
Swap Slots
스왑 파티션 내의 디스크 공간에 있는 페이지 크기의 영역 / 페이지 크기에 정렬 추천
Resource Management Overview
pintos에서 test를 통과하기 위해선 아래와 같은 자료구조들을 설계하고 구현해야 함
Supplemental page table
페이지 테이블을 보조해서, 페이지 폴트 핸들링이 가능하도록 함
보조 페이지 테이블은 각 페이지에 대한 추가 데이터를 이용해서 페이지 테이블을 보조
- 페이지 테이블 포맷으로 인해 생기는 제한 때문에 보조 페이지 테이블이 필요
보조 페이지 테이블을 사용하는 두가지 목적
- page fault가 발생했을 때 그 곳에 어떤 데이터가 있었어야 했는지 알아내기 위해 커널은 보조 페이지 테이블에서 폴트가 발생한 가상 페이지를 탐색
- 커널이 프로세스가 종료될 때 어떤 자원을 free할지 고르기 위해서 보조 페이지 테이블을 조사
보조 페이지 테이블은 내가 원하는 대로 구성할 수 있는데, 구조에 접근하는 최소 두가지의 기본적인 방법이 있습니다.
- 세그먼트 측면 ⇒ 연속된 페이지 그룹(ex : 실행파일을 포함하는 메모리 영역 / 메모리-매핑된 파일
- 페이지 측면
Handling page fault 페이지 폴트 다루기
보조 페이지 테이블을 사용하는 핵심 유저 ⇒ 페이지 폴트 핸들러
기존 페지이 폴트 핸들러는 항상 커널 또는 유저 프로그램의 버그를 의미 ⇒ 하지만 project3에서 파일 또는 스왑 슬롯에서 페이지를 가져와야 한다는 것을 의미
What page fault handler does
- 보조 페이지 테이블에서 폴트가 발생한 페이지를 찾음
- 페이지를 저장하기 위해 프레임을 획득 / sharing을 구현했다면 필요한 데이터는 프레임 안에 있을 것이고 해당 프레임을 찾을 수 있어야 함
- 데이터를 파일 시스템이나 스왑에서 읽어오거나, 0으로 초기화하는 등의 방식으로 만들어서 프레임으로 가져옵니다. sharing을 구현했다면 이미 필요한 페이지가 프레임 안에 있으니 별다른 조치 필요 X
- 폴트가 발생한 가상주소에 대한 페이지 테이블 엔트리가 물리 페이지를 가리키도록 지정
Frame table
프레임 테이블
물리 프레임의 eviction policy(직역하면 “쫓아내기 정책”)를 효율적으로 구현하도록 해줌
- 프레임 테이블에는 각 프레임의 엔트리 정보가 담겨있음
- 프레임의 엔트리에는 현재 해당 엔트리를 차지하고 있는 페이지에 포인터 / 선택에 따라 넣을 수 있는 기타 데이터
- 프레임 테이블은 비어있는 프레임이 없을 때 쫓아낼 페이지를 골라줌으로써, pintos가 효율적으로 eviction policy를 구현할 수 있도록 해줌
프레임 테이블에서 가장 중요한 작업은 사용되지 않은 프레임을 획득하는 것 ⇒ free 상태인 프레임이 없다면, 몇몇 페이지들을 프레임에서 쫓아내어 그 프레임을 free 상태로 만들어줘야 함
- 만약 쫓아낼 수 있는 프레임이 없는데, 스왑 슬롯마저 꽉 차 있다면, 커널을 패닉
Accessed and Dirty Bits Accessed 비트와 Dirty 비트
x86-64 하드웨어는 각 페이지의 페이지 테이블 엔트리(PTE)에 있는 비트쌍을 통해 페이지 재배치 알고리즘 구현을 위한 도움을 제공합니다. 페이지에 read 하거나 write 할 때, CPU는 페이지의 PTE에 있는 accessed 비트를 1로 설정합니다. 그리고 write 할 때 CPU는 dirty 비트를 1로 설정합니다. CPU는 절대 이 비트들을 0으로 되돌리지 않고, 대신 OS가 되돌릴 수 있습니다. 같은 프레임을 참조하는 두 개 (또는 그 이상)의 페이지들인 aliases 를 조심해야 합니다. aliased 프레임이 accessed 될 때, accessed와 dirty 비트는 하나의 페이지 테이블 엔트리에서만 업데이트됩니다 (access에 쓰인 페이지에서만). 다른 alias들에 대한 accessed와 dirty 비트는 업데이트 되지 않습니다. Pintos에서 모든 유저 가상 페이지는 커널 가상 페이지에 alias 되어 있습니다. 당신은 반드시 이 alias들을 관리해야 합니다. 예를 들면, 당신의 코드는 양쪽 주소 모두를 위한 accessed와 dirty 비트를 확인하고 업데이트 할 수 있어야 합니다. 또는, 오직 유저 가상 주소를 통해서만 유저 데이터에 접근하게 함으로써 커널이 이 문제를 피하게 할 수 있습니다. (커널이 아닌) 다른 alias들은 공유를 구현하는 경우에만 나타나야 합니다. 또는 당신 코드에 버그가 있을 경우에도 나타날 수 있습니다.
Swap table
스왑 테이블은 사용중인 스왑 슬롯과 빈 스왑 슬롯들을 추적합니다.
- 프레임에 있는 페이지를 스왑 파티션으로 쫓아내기 위해 ⇒ 스왑 테이블은 미사용된 스왑 슬롯을 고를 수 있도록 해야 함
- 페이지 주인인 프로세스가 종료되어 버릴 경우에 스왑 에티블이 스왑 슬롯을 free 해줄 수 있어야 함
- 스왑 슬롯은 느긋하게 할당되어야 함
- eviction에 실제로 필요할 때만 할당되어야 한다는 말
- 프로세스가 시작될 때 실행파일에서 데이터 페이지들을 읽고 곧바로 쓰는 행위는 느긋하지 못한 행위
- 특정 페이지를 저장하기 위해 스왑 슬롯이 예약되어서는 안됨
- 스왑 슬롯의 내용물이 프레임으로 읽혀 돌아오면 그 때 스왑 슬롯을 free
Reference
https://sergeswin.com/1034/