Paging의 문제 : Space overhead
32bit address space에서 4KB의 page를 쓴다치면 VPN은 2^20개 나오고, PTE의 사이즈가 4B라고 하면 2^22B즉, 4MB의 공간이 필요하게 됨 64bit라면? ㄷㄷㄷㄷ 너무 많아 !!!!!!!!!
(심지어 각 프로세스마다 필요함)
invalid PTE가 많더라 따라서 일부만 저장하자 !!
Paging with Segmentation
Virtual address space를 segment로 나누고, (이때 세그먼트 각 크기는 다를 수 있음) 얘네를 Page table로 보내서 page에 맵핑
요론 식으로 STBR로 보내고, 영역 밖에 있는지 체크한다음에 Segment랑 physical memory 연결
Paging with Segmentation의 장점
- page table 사이즈를 줄일 수 있다
- segment 크기를 늘릴 때, 통째로 옮겨서 늘릴 필요 없이 page를 하나 더 주고 PTE에 저장만 해주면 된다 !!
- 비슷한 이유, 일부 page가 disk에 있어도 run process
단점
-
그럼에도 불구하고 여전히 page table이 커질 수 있다.
segment의 수는 고정이어도, 예를 들어 heap이 크지만 sparse하다면 낭비가 많이됨
-
External fragmentation
Multi-level Page Table
Linear Page Table의 경우 PFN을 바로 넣으면 바로 찾고(대신 전체 리스트 뒤져야돼서 오래 걸림)
Multi-level Page Table의 경우 차근 차근 level별로 접근
즉, 뒤져야하는 list길이가 압도적으로 적다
Virtual Address가 이런 식으로 되어있다면,
찬찬히 접근
Multi-level Paget Table
Pros
-
address space가 사용될 때만 올림 ! valid bit 체크해서 fault나면 page 올려주고, valid하게 만들어주면 됨ㅇㅇ
-
page 사이즈 대로 잘랐으니 physical memory 관리하기 쉬움
-
External fragmentation 없음
Cons
- TLB miss나면 결국 memory access 더 많이 해야 됨
- 복잡하지,,
Inverted Page Table
기존의 page table은 virtual address -> physical address였는데,
만약 physical -> virtual address로의 정보를 저장한 page table이 있다면??
어디에 사용될까?
memory다 찼을 때, 만약 disk로 swap하는 경우 해당 PF을 가리키고 있던 PTE의 valid bit을 0으로 만들어줘야 한다 ! 따라서 해당 PF를 누가 쓰고 있는지 알기 위해서 이러한 inverted page table이 필요함 !!
+) shared memory에서 빼낼 때 얘네의 link도 다 끊어줘야 한다.
Paging Page Tables
: page table을 virtual address space에 넣는 것
안쓰는 page table을 disk로 보내버릴 수도 있겠지..
kernel code와 data를 page해버리면 fault났을 때 kernel로 가야하는데 또 fault가 날 수도 있다는 문제가 있다,,
