contents
Segmentation Architecture
의미 단위로 처리해야하는 일 → 공유, 보안을 하는데 있어서 Segment가 더 유리하다.
•
메모리 일부를 읽거나, 읽기 권한, 쓰기 권한을 준다고 하면 의미 단위로 하는 것이지 동일한 크기 단위로 하는 일이 아니기 때문에 페이징보다 Segmentation이 좋다.
◦
동일한 크기 단위로 잘랐을 때 유리한 점 → 페이징은 중간중간에 물리적인 메모리 조각이 발생할 확률이 없다. 같은 크기로 나누기 때문에 비어있는 페이지 프레임이면 어디든지 사용 가능
◦
Segment는 Segment 크기가 균일하지 않기 때문에 올려놓으면 물리적인 메모리 중간 중간에 Hole이 발생
→ 한 Segment가 내려가고 나면 그 Segment보다 작은 Segment들만 들어갈 수 있게 된다.
▪
Allocation 문제는 Segmentation의 약점
•
실제로 Paging과 Segmentation를 비교하자면,
◦
테이블을 위한 메모리 낭비가 대단히 심한 쪽은 Segmentation이 아니고 Paging이다.
◦
페이지를 같은 크기로 나누는데 4KB가 아닌 4MB로 나눌 수도 있겠지만, 일반적인 시스템에서 paging를 사용하는 페이지는 4KB.
◦
Segmentation은 프로그램이 몇 개 안들어가기 때문에 테이블을 위한 메모리 낭비로 따지자면 Segmentation이 낭비가 더 적다.
Example)
하나의 프로그램을 구성하는 Segment가 5개인 경우의 예시
그 중에서 Function, Stack, Symbol table이 하나의 Segment를 형성하고 있다.
•
각각의 Segment들에 대한 Segment table이 존재
•
Segment table에는 Segment들의 물리적인 메모리 상의 시작 위치가 적혀있음
•
Segment 별로 물리적인 메모리 상에 올라갈 수 있고 내려가 있을 수도 있음
Example) Sharing of Segment
세그먼트를 서로 다른 두 개의 프로세스가 공유하는 예제
각각의 프로세스가 두 개씩 Segment를 가지고 있음
•
Segment 0은 코드를 담고 있는 Segment → 두 개의 프로세스에서 Share(Shared Segment)
◦
같은 논리적인 주소 상에 있어야 한다. → Segment 번호가 같아야 함.
◦
두 프로세스를 위한 Segment 0의 물리적인 메모리 위치는 동일함.
•
private segment인 1번 segment는 두 개의 프로세스에서 주소 변환 정보가 다른 위치로 매핑되어 있다.
◦
별도로 존재해야하는 건 주소 변환을 따로 함
Segmentation with Paging(Paged Segmentation)
두 가지 기법을 혼합한 기법
Segment를 가지고 여러 개의 페이지로 구성하는 기법
세그먼트 하나가 여러 개의 페이지로 구성한다.
세그먼트가 하나의 여러 개의 페이지로 구성되기 때문에 먼저 세그먼트에 대한 주소 변환을 진행한다. |
각 프로그램이 가지고 있는 논리 주소는 세그먼트 번호와 세그먼트 안에서의 offset으로 구성된다. |
Segmentation 기법에서 사용하는 Segment 테이블을 찾아야 한다. |
Segment 테이블은 Register가 Segment 테이블의 시작 위치를 가지고 있다. |
그 위치에서 s번째 엔트리에 가면 이 Segment에 대한 주소 변환 정보가 들어있다. |
•
원래 Segmentation 기법에서의 테이블은 물리적인 메모리에서의 시작 위치값을 가지고 있다.
•
Segmentation 기법에서는 Segment가 통째로 메모리에 올라가기 때문에 시작 위치를 알려주면 되지만 Paged Segmentation에서는 Segment 하나가 여러 개의 페이지로 구성이 된다.
장점
1.
allocation 문제가 생기지 않는다.
•
hole들이 생기는 문제가 없어진다.
•
물리적인 메모리에는 페이지 단위로 올라가기 때문에 그렇다.
2.
Paging, Segmentation의 장점을 모두 가진다.
•
세그먼트는 페이지 개수의 배수로 구성된다.
•
의미 단위로 해야하는 공유, 보안 - Segment 테이블 레벨에서 관리
◦
특정 Segment가 어떤 보안이 read only인지, read, write인지 Segment 테이블에서 Segment에 표시한다.
•
페이지 단위 - 물리적인 메모리에 올라갈 때
오리지널 Segmentation만 사용하는 경우는 잘 없다.
Segmentation을 사용한다면 Paging을 사용해야지만 관리가 수월한 방법이다.
•
2단계 Paging처럼 주소 변환을 두 번 거쳐야 한다.
•
Segmentation에 대한 주소 변환을 하면 Page 테이블의 시작 위치가 나온다.(여러 개의 페이지로 구성)
•
Segment 당 페이지 테이블이 존재하기 때문에 각각의 페이지 별로 주소 변환을 해야 한다.
•
Page 테이블의 해당 엔트리에 가면 이 Segment를 구성하는 페이지 테이블의 시작 위치가 나온다.
◦
엔트리는 몇개로 구성되어 있나요?
Segment의 길이가 얼마인지 Segment 테이블에 담아둔다.
그 길이를 벗어나는 요청에 대해서는 trap를 발생시킨다.
◦
Segment의 길이보다 Segment 안에서 떨어진 offset이 더 크다면 잘못된 메모리 접근 시도를 의미
◦
반대로 offset이 길이 내부에 있으면 변환을 해준다.
•
다단계 Page 테이블처럼 offset d를 다시 자른다. 그래서 앞 부분은 페이지 번호로, 뒷 부분은 그 페이지에서 얼마나 떨어졌는지 보는 offset으로 사용
◦
d : segment offset, 세그먼트 하나가 여러 페이지로 구성되기 때문에 나눠서 사용
▪
앞 : 페이지 번호, 뒤 : offset
•
엔트리에 가면 이 페이지에 주소 변환 결과가 있고, 물리적인 메모리의 몇 번째 프레임, 페이지 안에서의 offset은 그대로 넘겨주면 물리적인 메모리의 주소가 된다.
각각의 페이지 별로 물리적인 메모리에 올라가게 된다!!
물리적인 메모리 관리
주소 변환에 있어서 운영체제의 역할 = 없다
다 하드웨어가 해줘야 하는 역할, like MMU
•
Segmentation, Paging
→ CPU가 논리주소를 주면 물리적인 메모리 주소로 바꿔서 메모리 참조
•
일련의 과정에서 운영체제가 하는 건 하나도 없음. 하드웨어가 해줘야 함.
1. 어떤 프로세스 하나가 CPU를 잡고 실행을 하고 있으면서 주소 요청 |
2. 메모리 참조를 해야하는데, 어떤 프로세스가 CPU를 가지고 있으면서 메모리 접근을 하는건 운영체제의 도움을 받을까? N |
3. 어떤 프로세스가 CPU를 가지고 메모리 접근을 하는데 주소 변환을 할때마다 운영체제가 개입을 해야한다고 하면? |
4. CPU가 프로세스로부터 OS로 넘어가야 하는 문제 발생한다. |
5. CPU가 운영체제와 프로세스를 왔다갔다 해야하는건 말이 안된다. |
•
IO 장치 접근만 운영체제가 끼어드는 일
◦
프로세스가 직접 IO접근을 못하기 때문에 운영체제한테 대신 해달라고 한다.
◦
CPU가 운영체제한테 넘어가서 해야하는 일
But, 메모리 관리는 당연히 하드웨어가 해야하는 일
•
CPU를 잡고 있으면서 주소 변환을 해서 instruction 형태로 운영체제가 일을 하게 된다.
•
사실상 운영체제는 메모리 관리에서 큰 역할이 없다.
◦
Virtual memory에서는 중요한 역할을 맡았다.