Search
💾

[OS] Memory Management 4

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에서는 중요한 역할을 맡았다.