주소 공간
- 프로세스에서 참조할 수 있는 프로세스의 공간
- 프로세스와 1대1의 관계
- 프로세스 하위인 쓰레드는 주소 공간을 공유함
물리 주소와 가상주소
- 실제로 메모리에 올라갔을 때의 주소와 스토리지의 주소를 구분하기 위해 탄생
물리주소
- 저장소에 저장되어있던 프로그램이 실제 메모리에 올라가게 되었을 때 어디에 위치되나(찐 메모리)
가상주소
- 프로세스 관점에서 사용하는 주소(0~1024)
기존에는 물리주소= 가상주소 라서 다양한 프로그램 컴파일시 주소를 Load하며 관리하기 어려움
=> 가상 주소와 물리주소 분리하자
가상주소를 언제 Fix할까?
Compile Time
- Symbol Table 때문에 실제 활용하기는 어려움
Link Time
- Symbol Table에 의존적이지 않은 주소를 만듬
LINK를 통해 하나의 Executable로 만들어져서 쓸만한게 나옴
Load Time
- Base Register 또는 relocate register로 위치를 찾아감
Execution Time
- 프로세스가 올려지는 메모리의 물리 주소는 바뀔 수 있다.
가상 메모리(PA and VA)
가상메모리 출현 배경들
1.매핑
- 프로세스 개수가 늘어나게 되면 점점 복잡해짐..
- 용량
- 메모리가 한정적..(필요성)
가상메모리 구현
매핑 정보
- 프로세스 1의 첫번째 메모리는 물리 메모리 어디에 있다 ~ 같은정보
- 매핑을 관리하는 테이블 (= page 테이블)을 가운데에 둠
- MMU 에서 다른 로지컬 넘버가 같은 피지컬 페이지 넘버를 가리키는 대참사를 방지하는 역할도 함
Paging
페이지
- 가상 메모리를 고정된 크기로 나누었을 때 하나의 블럭
프레임
-
물리 메모리를 고정된 크기로 나누었을 때 하나의 블럭
-
페이지 테이블은 각 프로세스마다 하나씩 있다.
페이지 테이블
- 각 프로세스의 페이지 정보를 저장함
- 프로세스 마다 하나의 페이지 테이블을 가짐
- 인덱스 = 페이지 번호
내용
- 해당 페이지에 할당된 메모리(프레임)의 시작주소.
- 이 시작 주소+ 페이지 주소 = 원하는 데이터가 있는 물리 메모리 주소
페이지 테이블 엔트리(PTE)
- 페이지 테이블의 기록
내용
- Page Base Address
=> 매핑 주소. 해당 페이지에 할당된 프레임의 시작주소 - Flag Bits
=> Accessed Bit. (페이지에 대한 접근이 있었는지)
=> Dirty Bit.
=> Present Bit. - Read/Write Bit
중간 퀴즈
1. 128MB / 4KB = 2^15=32K
2. 4GB/ 4KB = 1M
3. 바이트 단위 어드레싱이라고 가정했을때 log2 4K =12개의 비트가 페이지 내에서 어드레싱을 하는데 사용.
32bit 주소 공간에서 12개 비트가 페이지 어드레스 나타내는데 사용, 나머지 20개 =1M가 페이지를 구분하는데 사용
Translation Look-aside BUffers(TLB)
- 페이징 방법의 문제 해결방안(페이징은 데이터로 접근하려면 항상 2번의 메모리를 거쳐야하니까..)
TLB in MMU
-
캐시를 사용하는 방법과 유사
-
페이지 테이블을 이용해 변환된 주소를 TLB에 저장해둠
-
TLB 에 저장된게 있으면 물리 메모리안거치고, 없다면 페이지테이블 갔다가 접근
-
자주 사용되는 놈을 TLB에 저장해야함
Multilevel 페이지 테이블
- 배경: 가상 주소 공간도 너무 커져서 이에따른 페이지 테이블도 너무 커짐
- 페이지 테이블의 페이지 테이블 느낌
페이지 테이블 레벨과 성능
장점
- 페이지 테이블이 지금 사용하는 영역만 메모리에 올릴 수 있도록 해서 메모리에서 테이블 페이지가 차지하는 공간을 줄여줄 수 있다
- 계속 사용하는 매핑 정보만 참조를 하면 => 페이지 테이블이 차지하는 메모리가 줄어들 수 있음
단점
- 접근을 하는데 걸리는 시간이 오래 걸림
- 메모리 접근횟수가 늘어날 수 있음
(대안) Inverted Page Table
- 기존에는 페이지의 개수를 기준으로 삼아 프레임을 검색함. => 페이지 개수에 따라 용량이 늘어남.
- 반면 인버티드 페이지 테이블은 물리 메모리를 index로 만듬. => 한정된 용량 만큼만 페이지테이블이 만들어짐. => 검색은 페이지 아이디로
장점
- 페이지 테이블의 용량은 확 줄어듬
단점
- 페이지 ID에서 이걸 찾아가려면 전체 애들을 다 비교해야함..
(대안)Demand Paging
-
한정적인 메모리 문제를 해결함
-
프로세스 실행을 위한 모든 페이지를 메모리에 올리지않고, 필요한page 요청이 올때 만 메모리에 올림
-
필요한 페이지는 메모리에 있지만, 필요없는건 secondary storage에 저장함
장점
- 전체 물리 메모리의 양을 줄일 수 있다.
다점
- 참조하려는 페이지가 실제 메모리에 없다면 이에 대한 처리가 필요. => Page Fault
Page Fault
- 트랩으로 처리: 동기적인 이벤트니까!(정보는 저장할 필요없이 처리하고 바로옴)
- Page Fault 발생 빈도는 프레임 개수와 반비례함: (올려놓고 사용할 수 있는 페이지들이 많아지니까)
- 프로세스가 페이지를 참조할때 해당 페이지에서 받은 프레임이 없는 경우
=> 새로 프레임을 할당받아야함 => 이걸 Page Fault Handler가 해줌
Page Fault Handler
- 새로운 프레임을 할당받음
- Backing Storage에서 페이지의 내용을 다시 프레임에 불러들임
- 페이지 테이블을 재구성함
- 프로세스의 작업을 재시작함
Working Set
- 어떤 시간 Window 동안에 접근한 페이지들의 집합
- 시간마다 working set이 변함
성능을 최대한 잘 가져가려면
- Page Fault는 트랩을 통해서 Secondary Storage에 접근해야함. => 큰 overhead!!
- 따라서 Page Fault를 줄이는것이 중요. => 시스템의 메모리 크기, 캐쉬의 크기, 페이지 테이블의 크기를 고려해서 메모리를 설계해야함
working set을 얼마로 해야 페이지 Fault 빈도를 줄일수있을까?
- Thrashing
Page Fault가 자주발생해서 이를 처리하는 시간이 Execution보다 긴 상황
