물리적 메모리 관리
프로세스가 cpu를 가지고 메모리 접근을 하는 것은
운영체제의 도움을 전혀 받지 않음
주소 변환은 무조건 하드웨어적으로 이루어짐
메모리 접근시 운영체제 역할 없음
어떤 프로세스가 cpu를 가지고 메모리 접근을 하는데 주소변환을 할 때마다
운영체제가 중간에 개입을 해야한다고 하면
CPU가 이 프로세스로부터 운영체제로 넘어가야함
넘어갔다가 다시 프로세스로 와야 함 말이 안됨
cpu
프로세스 -> 운영체제
운영체제 -> 프로세스
말이 안됨
I/O 장치 접근
하나의 프로세스가 사용하는 메모리 공간이 연속적이어야 한다는 제약을 없애는 메모리 관리 방법
Process의 Virtual Memory를 동일한 사이즈의 page 단위로 나눔
Virtual Memory의 내용이 Page 단위로 noncontiguous 하게 저장됨
일부는 backing Storage에 일부는 physical memory에 저장
Basic Method
프로그램들을 물리메모리에 올려놓을 때, 빈공간 없이 효율적으로 메모리를 올리는 방법
1. 페이징 기법
2. 세그먼테이션 기법
주소변환 아키텍쳐
페이지 테이블은 어디에 저장되어야 하나??
페이지 테이블 구현하기
일종의 캐시
TLB는 최근에 일어난 가상 메모리 주소와 물리 주소의 변환 테이블을 저장하기 때문에 일종의 주소 변환 캐시라고 할 수 있다.
주소변환을 위해 캐시메모리 같이 접근 속도가 훨씬 빠른 공간이 필요해서 TLB라는것을 두었음.
( 데이터를 보관하는 캐시 메모리와는 용도가 좀 다름. 오로지 주소변환을 위한 캐시 메모리 같은것. )
TLB는 페이지 테이블에서 빈번하게 참조되는 entry를 캐싱하고 있습니다.
(전부 저장하고 있지는 않음, 자주 참조되는 몇개만. 메인 메모리보다 접근 속도가 훨씬 빠름)
그래서 메모리상의 페이지 테이블을 먼저 보기전에 TLB를 먼저 봅니다.
TLB의 정보를 통해 주소변환이 가능한지? 보고 가능하면 바로 주소변환이 이루어져 물리적 메모리에 접근가능 / 메모리에 한 번만 접근 가능
TLB에 없는경우엔 페이지테이블에 접근해서 일반적인 주소변환을 하면 된다.
TLB거쳐서 주소변환하면 f(프레임 번호) 얻음.
TLB에도 p(페이지 번호)와 f(프레임 번호)를 쌍으로 가지고 있음. => 이것이 페이지 테이블과의 차이점!!
TLB에서 p가 있는지 없는지 검사하기 위해서는 전체를 다 봐야함
( TLB는 page table처럼 인덱스로 찾는게 아니라서~ )
전체를 다 탐색하는것을 막기위해서 Associative register를 이용해서 parallel search(병렬적으로 탐색)가 가능하도록 해두었음.
TLB는 컨테스트 스위치때 flush해서 한번 비움. ( 프로그램마다 p - f 값이 다를꺼니까 )
메모리 접근시간 계산
TLB에 접근하는 시간 = e (입실론, 1보다 매우 작은 값)
메인메모리 접근하는 시간 = 1
TLB로부터 주소변환되는 비율을 a (1에 가까움)
이단계 페이지 테이블을 왜 쓸까?
컴퓨터에서의 목적 2가지밖에 더 있겠나?
속도를 빠르게 하던지
메모리 공간을 덜 쓰던지
페이지 테이블 2번 참조하기 때문에 속도는 더 걸림.
페이지 테이블을 위한 공간이 줄어드는 것
몇 bit 로 표현되어야 하는지 알아본다.
logical address (32-bit CPU에서 하나의 페이지 크기 4KB)
page table 자체가 하나의 page로 구성되기 때문에, page number는 다음과 같이 나뉜다.
( 각 page entry가 4B(=32bit) )
10bit의 page number
10bit의 page offset
따라서, logical address는 다음과 같다.
P1은 outer page table의 index
P2는 outer page table의 page에서의 변위 (displacement)
offset
정리
전체가 32bit (4G)
페이지 크기 하나 4KB (=2^12)
p2
페이지(4KB)에 들어가는 엔트리(4B)는 1K개 (2^10) -> 최대 크기 / 전체 사이즈 크기
p1 - outer page table의 index
[참고]
안쪽 page table (page of page table)은 원래의 page table (outer-page table)의 entry 1개를 각각 다시 page로 나눠 논 page table들을 가지고 있는 table이다. 즉 안쪽 page table 1개는 바깥쪽 table의 page 크기인 4KB의 크기를 갖게 된다. 또한 안쪽 page table 역시 entry의 크기는 4B일 것이므로 table 당 1K(1000)개의 entry를 가지게 된다.
P1은 outer page table의 index
P2는 outer page table의 page에서의 변위 (displacement)
offset
안쪽 페이지 테이블 하나에 entry 1K(2^10) 개를 넣을 수 있음
1K의 엔트리 위치를 구분하기 위해 p2는 10bit 가 필요
왜냐면 1K는 2의 10승
P1은 32bit에서 -12 -10 해서 자동으로 나머지 10bit임.
64bit 주소체계를 쓴다고 했을땐? P1,P2,d 몇비트가 필요할까? 생각해보기!
-> 주소공간 (16엑사..)
-> 페이지 하나의 크기는 (4KB) 라고 가정. => 4페타 개의 엔트리.
-> page offset => 12bit(페이지 크기에 연관된거라서 32bit, 64bit주소체계랑은 관련X)
-> 4KB안에 8B짜리 엔트리 -> 1/2K => 512개(2^9) => 9bit임....
/43bit/9bit/12bit
사용 이유
과거
Two-Level Page Table 사용함으로써 해결
요약
20 강
- Address space 가 더 커지면 다단계 페이지 테이블 필요
page table entry 개수
valid (v)
Protection bit
공간 오버헤드 막아보자
physical memory의 page frame 개수만큼 page table 존재
주소 변환 방법
Inverted Page Table
cpu -> logical address 가짐 -> pid, p를 page table에서 찾기
-> 찾으면 위에서 몇번째인지 본다 (f) -> physical memory f 에 올린다.
해결
associated register 에 넣어서 탐색하면 순차검색의 타임 오버헤드 줄일 수 있음
한글 3개 띄웠다고 가정
공유하는 부분은 한 개만 물리적 메모리에 올리기
제약 조건
21강
segmentation
paging
Segmentation Architecture
cpu가 논리 주소 줌 -> s,d -> s만큼 떨어진 entry에 간다. -> 어떤 번지에 들어가 있는지 안다
segment 크기가 균일하지 않음 (allocation 문제 생김)
의미 단위로 작업을 수행하는 경우 유리 (공유, 보안에 효과적)
STBR
s < STLR -> trap 발생 시키기
(s : 레지스터 번호)
Segmentation Hardware
테이블 entry
주소 변환 가능
base + d
segment
같은 논리적 주소상에 있어야 함
segment 번호가 같아야 함
ex) segment 0 43062
private segment
ex) segment 1 주소가 다르다
segment 하나가 여러 개의 page로 구성
각각의 page 별로 주소 변환
segment 당 page table 존재
page table base : page table 시작 위치
segment length : page table에 몇 개의 entry가 있는지
s + d
d <= segment length -> True
d : segment 안에서 떨어진 offset 값
segment offset (d) 를 자른다.
page table base (시작 위치) + p(page 번호) -> f (물리적 메모리의 frame 번호)
f + d'
현실에서 메모리 관리시 segment 따로만 사용되지 않음
STBR : 시작 위치