base & limit register의 한계
→ protection, relocation은 해결했지만 bloatware
- bloatware란? memory 크기 증가보다 소프트웨어 크기가 더 빠르게 증가
→ 해결 방법
1. Overlay 옛날방법
: programmer가 프로그램을 나눠서 올림
→ overlay 한번 더 call하면 memory→disk로 swap
2. Virtual Memory
: only parts of address space are loaded into physical memory
Paging
e.g. MOV REG, 1000
→ virtual address 1000은 MMU에 의해 physical address로 mapping
- process의 address space
① Swapping의 단점 해결
➁ Virtual→Physical로의 주소 변환
-
virtual address space와 physical memory가 fixed size unit으로 나뉨
: 해당 mapping정보는 page table에 저장
e.g. MOV REG 8196 → MOV REG 24580
: 어디로 mapping됐는지 항상 기억하고 있어야
➂ Page Fault
: when accessing unmmapped page
→ trap to OS
→ OS가 LRU에다가 PT변경 → frame에 하나 할당
: 더이상 가상 page x1이 mapping x, 새로 가상 page x2가 mapping됨
→ fault 발생한 instruction restart
Page Table
① Page Table이란?
- page table의 entry는 virtual address space의 허용범위에 따라서
- DRAM에 저장하는게 유용함
offset
그림에서 offset = 12bits
∵ allocation unit = 4K
→ page의 시작부터 얼마나 떨어져 있는지??
virtual->physical 계산 방법
- MOV REG, 8196이 실제 어떤 frame에 mapping?
→ 8196에서 /4k 혹은 밑에 12bits 떼고 보기
page fault
: 아직 frame에 올라오지 않은 경우 (disk에 저장되어있음)
→ 내가 찾는 page가 DRAM에 x
→ disk에서 갖고오면 시간이 너무 오래걸림
→ process가 CPU 포기
→ 다른 process 수행
➁ Paging example
VPN과 offset 비트수 계산하기
- 32bit 주소, page 크기:4KB
→ 4KB = 4096 bytes = 2^12bytes
→ offset: 12bits, virtual page number: 20bits (2^20개의 page)
변환하기
- 0x13325328 변환하기
- VPN : 0x13325
- offset: 0x328
→ PTE 0x13325가 0x03004로 mapping된다고 가정
→ physical address = PFN :: offset = 0x03004328
➂ virtual → physical로의 변환
: virtual addr은 virtual page number :: offset으로 구성
→ physical addr은 page frame number :: offset
1 PTE per VPN
➃ Page Table Entry (PTE)
: 각 entry마다의 정보를 나타냄
-
present/absent (valid)
: PTE가 이용될 수 있는지?
→ 0: 해당 PTE가 비었음 → page fault (frame에 올라오지 x) -
reference bit
: 해당 page가 fetch, ld, st될때 set -
modify (dirty) bit
: 해당 page가 update 되었는지?
→ (주로 store) page에 write할때 set
e.g. st R0, ...
→ 해당 page update : DRAM과 Disk의 정보 달라짐 -
protection bit
: controls which operations are allowed
→ read(page의 data fetch), write, execute(해당 page의 명령어 수행 가능)
: page의 특성으로 없는데 하면 fault 발생 -
page frame number
: physical page 나타냄
→ physical page start addr = PFN << (#bits/page) -
caching disabled
: I/O page for memory mapped I/O
→ data중 L1, L2등 캐쉬에 올라오면 안되는 데이터가 있음 e.g. I/O 사용 데이터
: 해당 페이지에 접근하지 못하게
➄ Page Table의 저장
방법 1 HW register에 저장
- mapping시 memory reference 필요 x
- entry가 너무 많아 cost가 너무 비쌈
→ 불가능
방법 2 main memory에 저장
- PT의 시작주소 담고 있는 register
- fast memory map change by reloading 1 reg (∵ OS가 PT의 시작정보 알고있기 때문)
- requires memory reference during excution of each instruction
→ 매번 DRAM 2번 접근 → overhead
➅ Paging의 장점
-
memory의 할당/반환이 쉬움
∵ page단위(allocation)로 memory가 들어오고 나가므로 -
No external fragmentation
∵ page단위 이므로 -
DRAM < process 크기여도 상관 x (VAS > PAS)
∵ 현재 쓰는 frame 몇개만 있으면됨, 전체가 다 올 필요가 x↔swapping
- 프로그램의 전체
- 어디가 비었는지 알아야함
- fragmentation 발생
- 사이즈 계산해야함
➆ Paging의 단점
-
Internal fragmentation
∵ page를 다 쓰지 못해서 한 페이지 다 써야함 -
memory reference overhead
: page table이 메인 메모리에 있어서 매번 DRAM을 두번 access→ 해결법 : TLB사용
-
page table의 overhead
: PT을 위한 memory 공간이 너무 큼 & process마다 할당
e.g. 32bits의 AS with 4KB page
→ 2^20 PTEs = 1048576 PTE
→ entry당 4B = 4MB/PT
frame# 2^36 4KB = 2^38 = 4GB 2^g
→ entry가 클수록 속도 느려져 entry 많이 만들 수 x
